5

In a couple of weeks I will be joining a project that (currently) uses LabView for development. To get myself at least somewhat familiar before this happens I have been creating some simple projects in the trial version of the software. Someone challenged me to write a simple program that could preform simple division without using the division operator.

I've written the program successfully, but my main while loop seems to run one too many times. Here is my program:

program image

The user inputs a dividend and divisor and the program will continually subtract the divisor from the dividend until the dividend becomes <= 0, at which point it should break. The program runs successfully, but when the loop finally stops the dividend always equals x below 0 (where x is whatever number the divisor is). While debugging the application I found the problem, when the loop comparison happens for the final time the dividend will equal 0 and evaluate to 'false' however the code inside the loops executes one last time before the loop breaks. This is what I would expect from a do-while loop, but not a simple while.

Just to prove to myself that it wasn't an (hopefully) obvious logic error I wrote (what I consider to be) an equivalent program in python that does exactly what I expect.

I've spent a long time googling, staring at it, I even did it on paper but I cannot figure out why it doesn't do what I expect. What gives?

Seth
  • 528
  • 3
  • 16
  • 32
  • Not an answer, but comment regarding variables in LabVIEW. As you noticed, LabVIEW requires you to think differently than other programming languages. Sound program logic transferred "as is" from other language can make you a terrible example of how to do not program in LabVIEW. Variables and Sequence structures are two main constructs that get abused by beginners. Just by avoiding using them where they are not required you will start to think LabVIEW way. – skof Dec 22 '14 at 13:29

3 Answers3

3

LabVIEW executes it's code according to the dataflow principle Which means that the loop cannot stop, until it has finished executing all the code inside it. This is the NI document confirming the above (see the very first flowchart). Moreover, subtraction and comparison are happening simultaneously.

The code you have is largely equivalent to (except that comparison with 0 happens on a temporary value in the wire) :

dividend = YYY
divisor = XXX

dividend = dividend - divisor
while dividend > 0:
    dividend = dividend - divisor 

If you'll be really getting into LabVIEW I strongly suggest you avoid using local variables. Many times (including this one) they are bad. Do it like this instead:

enter image description here

This is a snipplet, so if you drag this file from explorer and drop it onto your BD it will appear as a piece of code (LV2014).

Seth
  • 528
  • 3
  • 16
  • 32
mzu
  • 723
  • 3
  • 13
  • Thank you! That makes a good deal of sense. Can you explain a little more why using variables is a bad idea? I know it is to prevent race conditions (and that is a good enough reason in itself) but are there any other reasons? LabVIEW seems to have a very different way of thinking about things than the programming I am used to. – Seth Dec 20 '14 at 04:22
  • 1
    Variables can be bad. Race conditions is #1 #2 is that by using the local variable you update the front panel control. Not necessarily synchonously, though, but still. #3 extra data copies during execution. (turn on Tools->Profile->Show Buffer Allocation) to see where extra data copies can appear. So, unless you are accessing your FP elements this way, do not use locals. Even when accessing your FP elements, check this reference: http://digital.ni.com/public.nsf/allkb/74ECB57D3C6DF2CE86256BE30074EC47, there might be a better way – mzu Dec 20 '14 at 04:25
  • Oh one last question, I currently do not have LabVIEW 2014 installed (just 2013) so I cannot copy your image. What are the up/down arrows on the edge of the loop, connection several of the controls? Are they shift registers? – Seth Dec 20 '14 at 04:30
  • They are. RMB on the border of the loop -> Add shift register. They act sort of like local variables per loop – mzu Dec 20 '14 at 04:33
  • 1
    For some reason, LabVIEW is not very popular on stackoveflow. For a dedicated community you can go to http://www.labviewportal.ru/viewforum.php?f=41 or http://lavag.org or http://www.ni.com/forums – mzu Dec 20 '14 at 04:42
1

I believe that the evaluation of the condition and the subtraction happens in parallel as opposed to after each other that's why you always get one more subtraction than you need.

Edit

As it's told in the dataflow tutorial (Figure 2) any operation as soon as all inputs are available can be expected to be executed. You can not know and should not rely on the order of execution for operations that are ready to be performed.

fejese
  • 4,601
  • 4
  • 29
  • 36
  • That is a logical conclusion based on my output, but could you find an official statement to that effect in the documentation somewhere? I have a hard time understanding why they would implement it like that, it is unlike any while loop I have ever used. – Seth Dec 20 '14 at 02:31
  • ok, that makes a lot more sense, I don't understand why it would be written that way, seeing as it doesn't exactly conform to a normal while loop, but I can live with it. Can you suggest a viable workaround to the problem? – Seth Dec 20 '14 at 03:00
  • You can either use a `Sequence` structure, or wire the result of the subtraction to the comparison instead of the original `dividend` – fejese Dec 20 '14 at 03:07
0

The Python code you've written is not equivalent. A while loop in LabVIEW is actually a do while loop, the code it contains will always execute at least once. This also means that the condition isn't evaluated until after the code it contains has executed.

Ryan Duell
  • 182
  • 6