I have recently observed behaviour from LabVIEW which seems inconsistent with my expectations.
If I have a piece of code which is fed a VI reference and I want to register events for controls on that Front Panel, I need to wait for the Front Panel to be loaded. I normally do this by polling FP.State and waiting for "Normal", "Hidden" or "Maximised". The showing of the FP is handled by the VI itself and after initialisation (which is running in parallel to this piece of code in question) then I can register the events of the controls on the FP.
However, from time to time this property seems to not accurately reflect the actual status of the FP state. It happens occasionally that although VI Server returns a state compatible with being able to register events for FP controls, some event registrations do NOT work as the references are deemed invalid (as if the property is being set slightly before the VI is actually initialised, it feels like a race condition TBH). Problem is that we need to be able to filter out really invalid references, we cannot differentiate between "Invalid because the FP isn't loaded" and "Invalid because the user wired nothing". As such we need to be able to rely ont he FP.State property.
Does anyone else have similar experiences? Does anyone have an alternative method?
Take this example. A sub-VI receives a VI Reference and an Array of references of Controls on that VIs FP. In reality we have the option of receiving many different arrays for different functionalities, and not all are guaranteed to be valid (Empty arrays, default values and so on). Therefore we are required to make a sanity check on all of the references. If you wire a single invalid reference to the "Register for Events" then all registrations below this int he same node will not work. For this, we need to wait for the FP to open which we ensure by polling the FP.State property and progressing as soon as it is "Standard", "Maximised" or "Hidden". We immediately then perform the validity check ont he references.
Problem: Sometimes the first few comparisons return "invalid" for the references even though we know that it should be valid. If we repeat the action a few seconds later, everything works fine as expected. The behaviour would seem to indicate a difference in time where the FP-State property gets set to tha appropriate value and the FP actually being loaded. When running this code in the IDE we never encountered a problem but in our built EXE customers have observed that certain buttons have no function which we have managed to narrow down to this issue. Sounds like a typical race condition, right?
It's not my personal experience but that of a co-worker. LV 2012 it must be said.
We register quite a lot of arrays in one node and apparently one "invalid" reference will stop the rest from registering. I'll ask for an example.
But back to the issue: We found out something really weird today. During debugging we decided to look at the DECIMAL values of the references as they are passed into our validity check. The reference for the elements which did not register (which were sorted out were NULL (decimal zero)). However, using the SAME reference (not re-reading the static reference, but the same Reference VALUE passed into our data cluster) we could later register properly for events and the decimal value of the register became magically not NULL (decimal not zero). We write this reference only once in our software from a static reference int he top.-level VI so I don't know how this reference can be NULL when first reading and then magically become not NULL later on.
Picture this: Pass a static reference to a FP control into a sub-VI where it is in turn passed into a WHILE loop (no shift register) and start getting the decimal value of the reference. If you open the FP of the owning VI (i.e. where the control is) during the time where the loop is running, it will change from zero to a proper value. This feels very wrong? Is there some behind-the-scenes magic (black magic) going on here we should be aware of?
Anyone have any ideas?
For what it is worth...
You can right-click a node and choose "Ignore errors in...". The icon will chagne its look and errors will not prevent subsequenct properties from working.
I recall you had some trouble with dynamically loading VIs and finding the VIs being loaded where not completely loaded even though the "Open" had returned. I think you were doing this to load VI's into sub-panels.
Did you you just add a wait or did you do some poking to verify the VI had loaded?
Hi all, here's Intaris' co-worker who encountered the issue, with more visualization material. Important to know is that these reference values get invalid only in compiled code, it never occurs in development. A printscreen of the code section where the issue occurs. It's in a subvi that prepares the control references for dynamic registration.
References are gathered and reshaped into a 1-dimensional array (as 2-dimensional arrays cannot be dynamically registered) and to remove the invalid references, there's this subvi with variant connectors, a printscreen of the block diagram here below:
To debug we tried to add some additional checks and wired the values out of the subvi.
So we found out, that sometimes - and not always reproducible - the first or the first two values of an array of (mostly three) references are zero and invalid, even that before the subvi, they're still non-zero and valid. This control reference check vi with variant connectors is inlined, interestingly the issue that a reference gets invalid never occurs (in about 50 tests) when we don't inline the subvi. So we suppose now it's a Labview bug that is related to inlining and the front panel state being "hidden" (it never happens when the FP is "standard"). We have also the impression, the probablity it occurs seems to be related to some PC environment (performance, execution time?), as customer reported this issue to be reproducible on every run of the application.
Anyone else encountered a similar issue already? Right now we'll go with the workaround to not inline this reference validity check subvi.
In addition, it almost goes without saying that attempts to recreate the issue in a smaller cut-down version of the software showed no anomalous behaviour.