LabVIEW
Correct Shared Variable behavior
I have a program, written in version 8.5, that has a shared variable used in an number of locations to shut down the program's major loops when the test system is being "shut down". I used a SV specifically to use its error in/out to force the execution order in these various loops. In 8.5 it has worked correctly, but yesterday I was helping my customer commision a new test system, using this program, and they only have 8.6, so we decided to migrate it all to this version. While still debugging the test system hardware we got an error which caused me to attempt to terminate the program. At this point I noticed that all but one loop had terminated correctly, and when I probbed the no terminating loop I discovered that it had had a hardware error, putting an error on the loop's error cluster. This caused the boolean Shared Variable to output a F rather than the T that had been written to it when I attempted the shutdown. This wasn't the behavior I remembered in my 8.5 version, so I created a quick little test, two parallel loops, one with the boolean SV in the write mode with a control to toggle it F/T the other loop having the SV in the read mode, with its output set to stop the loop if T. I had an error cluster shift register in the second loop, with the SV's error in/out connected to it that had a control to introduce an error in the error cluster. On the system running 8.5 writing a T to the SV stops the loop regardless of the error cluster state, but on 8.6 it does not, with the SV returning a F if there is an error present.
Has this been seen by others? Which is the correct behavior? I ended up doing a really quick change, making a "real global" and putting it into a case statement within a VI so that I could retain the ability to have the error in/out chain. I should have used a functional global, which is my normal mode rather than a "real global" but was tired and had just had an educational discussion with my customer about SV vs Globals and for the few minutes it took was in the "global mindset". I think it might be the first global I've used in a couple of years or more, I just was so flabbergasted about finding the apparent change in behavior.
The quick glance I gave it yesterday was inconclusive, mainly dealy with the other arcania of shared variables. Did a quick search on NI site yesterday too, without any answers (it was a quick search as I was squatting on the customer's laptop as I don't have internet at their facility). What bothers me is the apparent change in behavior. If it is truely operating differently it threatens a lot of work I have done. I'm pretty sure that the behavior has been consistent from the introduction of the SV, seem to recall performing an experiment quite a while ago (8.2?) to determine the error behavio, so if it has changed, whether philosophically it is now correct, it could play havoc with a lot of code out there. Really makes it hard to maintain code, and reinforces my caution to customer about upgrading versions unless the new version has compelling features to justify it.
Thanks for the test, wanted to make sure that in the rush to get out of Erie before the predicted snow storm that I had actually seen what I thought I saw. Now the question is, is the difference in behavior intentional or a bug in 8.6?
IMHO if a function's behavior hasn't been specifically defined for 3 major release cycles, and it performs one way, it shouldn't be changed, regardless of some philosophical "standard". Pre-8.6 it behaved by passing the error through, but still performing its own task, output the value written to it elsewhere, so why would someone think that making this behavior change to "if an error is present output the default" would not have major implications? We don't all have the luxury of rewriting our projects from scratch. Worse yet, no where in the "release notes" , "known issues", "changes since 8.6", do I see this mentioned. I wouldn't have known about it, possibly for some time, if in debugging the test system hardware we hadn't had a hardware error (which hadn't occured in the prior three months of "ringing out" the hardware) that generated and error on the error cluster. The shared variable was in the various loops in my program to allow them to be stopped if an error was detected, or the operator was shutting down.
I would suggest that you use some type of "functional global" also called a LabVIEW 2 style global which uses a shift register on a while loop as the memory storage element in a while loop wired to execute only once (the stop node is wired "stop")rather than "real globals" unless you encapsulate the global in a sub-vi,. You can wire an error cluster straight through to allow the resulting vi to use the error chain for execution order control, as I had planned with the Shared Variable. You can also have a write case, read case, etc. inside the loop. Search on the this board for "functional global" or "LabVIEW 2 style" (there were no globals back then).
My fix at the moment is that I drove 250 miles (400 km) through a snow storm last night, am going in this morning and scrubbing the 8.6 based machine and installing 8.5.1 to make both machines identical. I would have done this originally (and not found out about this issue) but last week I forgot to pack my 8.5 DVD's and the customer only has the 8.6 ones at this time. They will be calling the NI office that handles them for their own, I suspect.
