bad boolean control reference bahavior

[david_jenkinson]

Hi,
We have an application where vi1 passes a boolean control reference to vi2, when launching it dynamically. Both vis are looping running asynchronously.  Intermittently, we are seeing a situation where when the vi1 boolean goes true, vi2 boolean does not(the boolean in vi2 controls saving of grabbed camera images to avi frames).  I have verified the behavior by putting some debug code in each vi, and saving a time stamp when each goes true.  The majority of the time, the timestamps are the same (which they should be), but we see a condition where this is not the case intermittently, causing an error when we go to copy the video, because the video does  not exist (never started acquiring frames).

To add to the confusion, we have 4 identical test stations, all running identical code (perforce source code controlled).  I saw this behavior on one other stations last month, and for lack of a better solution, re-installed all NI software (labview, teststand, vision, toolkit).  It actually seemed to help in that instance, because I have run several overnight runs since without the problem re-occurring.  The other 2 stations run 24 hour runs as well, without issues.  So it made sense to try this on the current problem station, but it did not help.

So in an effort to gather more data, I added more debug code.  If vi1 boolean timestamp > vi2 boolean timestamp, then write a log of the condition with all pertinent data, and don't try to copy the video (so we can keep running without error).  I ran for 8 hours, and I have 10-12 of these occurences where the boolean reference seemingly does not pass the value correctly, speckled throughout the 8 hour test run.  (I attached this file, the time values are seconds since 1-1-1904) 

I am completely at a loss at this point as to how this behavior might be possible.  Isn't a reference just a pointer to memory?  If it works at all, which it does most of the time, then I know the reference is being  passed correctly.  The 2 vi's are lauched at the beginning of the test run and stay running until the end, they are not re-launched. I s there some sort of coding guidelines I am missing?  The reference in vi1 was created by right-clicking on the boolean control, and "creating reference".  This value is passed to vi2 when launched dynamically.  Then in vi2 the "value" is retrieved in a loop.  Like I said, this code runs on all other stations, and actually has not changed for several months.  We did however just install the Q3 NI disks in Nov 2007, and have not run the station in question very much if at all since then, so it may have had the problem since.

So my question is, are there known issues with control references and their use?  I would sure be interested in any theories, because I am really scratching my head at this point.  I am contemplating another re-install, but that seems futile.

Thanks for reading this and your attention to this matter,

David Jenkinson

[MikeS81]

Hi david,

did you try to wait for a valid refnum in your vi 2. I think it can be possible that there are timing problems and so your refnum is not valid. I had the same problem and now i ever check for a valid refnum if i pass a refnum to a dynamic called vi.

The picture shows what i mean. I hope it helps.

Mike

[johnsold]

David,

I think control references require a context switch to the UI thread, although I am not certain. That would not seem very likely to produce errors as large and the hundreds of seconds you are seeing.

Have you tried passing the data via a notifier, a queue, or an Action Engine? Any of these should work for what you are trying to do and avoid problems of getting control values via references.

Lynn

[david_jenkinson]

Lynn,

Those are interesting suggestions.  I had not thought of using notifiers (never used them), or "action engine" (which I've never heard of, but am probably about to get very familiar with).  We have however used queues, that is actually what vi1 is, a queued stated machine that waits for queue messages sent by teststand steps (calling a vi which writes to the queue).  It actually works quite well.

It still seems strange that I've only seen this behavior on 2 of 4 machines, one of them seemingly fixed (so far) by a re-install of all NI software.  The PC hardware is exactly the same also. 

We have also seen weird control reference behavior in another instance, where we use a vi with a subpanel in a "wizard" type of application, and the subpanel vi has button control references passed to it.  Occasionally, but just often enough to be a real pain, we will see the subpanel vi code act like 'done" was clicked, but not next.  Most of the time it works flawlessly though.  It seems like this might be related to the same cause, whatever that is.

Thanks for the suggestions!

David

[johnsold]

David,

An Action Engine is a functional global VI, often with enhanced features. At minimum it is a while loop which exits after one iteration with an uninitialized shift register. Search for Ben's Nugget on the Action Engine.

I never use control references to pass the value of the control (only for setting properties, such as visibility or captions), so I don't have any experience with the performance issues you are having.

Lynn