LabVIEW
Can these constructs be used in LabVIEW as well?
Solved!
Hi Rong,
@RongTime wrote:
StartPoint as SP = 5
EndPoint as EP = 10
MovePoint as MP = 7
if(SP eq MP)
if(SP eq MP and MP < EP)
null
else
return
else
if(SP eq MP)
if(SP eq MP and MP < EP)
else
return
Is it possible to use a return similar to the one highlighted in red in a LabVIEW case structure?
Well, you can replicate nearly everything in LabVIEW as it is a full-featured programming language.
- Can you explain what those "return" commands exactly do?
- And what's the "null" command for?
Search LabVIEW like a graph! 
@RongTime wrote:
Hello
StartPoint as SP = 5
EndPoint as EP = 10
MovePoint as MP = 7
if(SP eq MP)
if(SP eq MP and MP < EP)
null
else
return
else
if(SP eq MP)
if(SP eq MP and MP < EP)
else
return
Is it possible to use a return similar to the one highlighted in red in a LabVIEW case structure?
That code will return nothing, all the time. Since SP != MP it'll go to the else case which do the same comparison again and thus does nothing.
@RongTime wrote:
Hello
StartPoint as SP = 5
EndPoint as EP = 10
MovePoint as MP = 7
if(SP eq MP)
if(SP eq MP and MP < EP)
null
else
return
else
if(SP eq MP)
if(SP eq MP and MP < EP)
else
return
Is it possible to use a return similar to the one highlighted in red in a LabVIEW case structure?
That code has both syntactical and logical errors as well as unneeded statements:
syntactic errors:
The second if(SP eq MP and MP < EP) has no corresponding statement to execute.
logical errors:
The code will never return anything. Even when considering that the value assignments at the beginning are just for debugging and will be in the real world variable (at least the MP I would hope), the code will either execute the first half of the statement branch (when SP eq MP) doing a null statement (what is that) when MP < EP or return otherwise, and otherwise it will always do a return since SP neq MP but you check again for SP eq MP, so the first branch with the erroneous if statement without any executable body, will never execute.
Unneeded code:
You check for SP eq MP and then inside that you check again for the same condition ANDed with a different condition. The second check for SP eq MP is unnecessary as it will be always true at that point.
Generally you should first think again about this code and the actual conditions. It looks like you try to do same range checking and then probably intend to do some more processing such as a simple P, PI or PID calculation.
LabVIEW has an In Range operator that makes the whole range checking very simple with a single node.
Thanks for the answers above
But I solved it the way I thought
While the motor was moving to the point I wanted, I needed to verify that the motor had reached the point I wanted, and in the process, I had questions about whether I could use continue and break in LabView.
I solved this using a for loop, but if you have any other knowledge, please share it.
thank you very much for your reply
@RongTime wrote:
Thanks for the answers above But I solved it the way I thought While the motor was moving to the point I wanted, I needed to verify that the motor had reached the point I wanted, and in the process, I had questions about whether I could use continue and break in LabView. I solved this using a for loop, but if you have any other knowledge, please share it. thank you very much for your reply
And you run right into the next problem! Comparing floating point values on equality is pretty much always an error!
Definitely with a motor as its position will be almost never EXACTLY at the position you try to compare to, so your loop will never stop and the motor will keep moving. Depending if you move forward or backward you should make that either an <= or >= comparison.
@RongTime wrote:
I used DBL for the example In testing and actual use, I think there is no problem because I used I32. Thanks for the good point 😄
Even then it won't work unless your motor is moving extremely slow!
Your loop has a certain time resolution, your motor position a certain position resolution.
Suppose you want to test with setpoint 40 and your motor moves fast enough that not every single position increment is caught by the loop reading the position. So one iteration it reads 39, the next iteration it reads 41! Et voila, your loop will not stop.
But, but! I tested it and it works! Maybe it does now, because you use low velocity for the test. Then you deploy the system and your user enters a higher velocity, since he wants the system to work a bit more efficient. And now your motor regularly runs over the desired position and keeps running until it bumps into the end position, depending on the strength of the motor with more or less catastrophic results. Sometimes it works, as the returned position by chance matches the position you want, but often it will not.
Another source of inaccuracy is the loop timing. Yes LabVIEW is compiled and very fast, but you must read that position somehow, which requires communicating with the motor. That communication might happen over a slow serial line. Or you keep adding extra functions to do more things in the loop, slowing down the loop considerably. And you are not executing in a real time system, so Windows can happily decide that it wants to start a virus scan, or its network driver urgently needs to fetch data from the network card, or anything else, and suspend your LabVIEW process for milliseconds or even seconds, in which time LabVIEW can't execute that loop, no matter how hard it tries to do anyways.
Don't test on equality if there is even the slightest chance that your result might not always be exactly what you expect, and in the real world all measurements are generally that way!
