I have a VI library created in LabVIEW 6.1 with a few bugs/glitches in it. Admittedly it uses a while loop instead of an event structure as its main operator, but I've not had the time to look into the alternative fully yet. It is still under heavy maintenance, so there are a few incomplete parts to it. However, all its basic functions do still work. I enclose both the VI library and a picture of the main VI showing its default code. My main problem is with the 'atten step' variable (scroll bar on the FP). If you play around with it a bit whilst the VI is running (go wild - your aim is to observe it breaking), I'm sure you'll discover at least one of its problems. I have yet to find the root cause(s) of the problem(s) with this particular variable. I am wondering if there is a possible race condition here (though it doesn't show up with the light bulb/illuminator on) due to its local variable...? Either way, could someone (anyone) please have a look at this to see if they can work out one/some of my many problems! I will warn you that the names of a few of the variables do change slightly amongst the VIs (due to 'parallel construction') but not so much that they become unrecognisable. There is also some defunct code in there resulting from modifications for added effectiveness leaving a previous work-around unused. I should also note that I've not yet assigned the correct error messages to invalid entires to the keypad - you may notice that yourself though! If there are questions on its operation that need querying, or if you don't think you can find some of the problems, I'm more than happy to go into detail - just didn't think I should make the first post too long! Thanking you in advance. Message Edited by James Mamakos on 04-30-2009 01:13 PM

LabVIEW

Problem with VI - unidentified cause - possible race condition.

James,

The quotient would be 1 if they are equal.

This has the same problem. The best algorithm is to take the absolute value of the difference between the numbers and ask if that is less than some small number. Recent versions of LV have a built in constant on the Numeric palette called Machine Epsilon ~ 2E-16. This is the smallest number which when added to 1 gives a result which is different from 1 for double precision numbers. It may vary with OS and computer hardware. In many practical cases you may want to use a number larger than that, particularly if the numbers you are comparing are the result of a chain of calculations where the finite representation error may have been accentuated by the processes.

Here is a VI (LV8.2) I wrote some time back to deal with this issue. This tests for equal to zero +/- .000001. It could be modified to test for equality of two doubles.

Lynn