Ether's worry about clipping vs. normalization is valid, and you do need to correct your code to handle it properly, but I don't think the input values you're testing would cause an issue in this particular case.
Quote:
Originally Posted by jman4747
Also the values are computed in order, that is to say that if D is equal to C*Pi and C = A*B it will wait to get A & B compute C, compute C*Pi then give D. Nothing happens with D until everything it is dependant on happens. Or that's what I observed at least.
|
Because you have separated the processing steps into disconnected parts, they will not necessarly run in the order you expect. The output-clipping section will use whatever values are in the local variables, whether or not the speed-mixing section has completed and updated the variables first.
Your first task in correcting the VI is to eliminate all local variables. Let LabVIEW do what it does best. Instead of storing a value in "A" somewhere and reading "A" elsewhere, just run a wire from the source to the destination. You can -- and should -- wire a single source to multiple destinations.
Then you can implement the necessary normalization. It's a lot easier than you're making it look, and it's even easier in LabVIEW than the C code implies.
Finally, you can do some serious optimization of the math. There's no need to have four copies each of "180" and "π" when converting from radians to degrees. You can just do the 180/π division once and multiply each angle by that result.