From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
02-01-2012 03:44 PM - edited 02-01-2012 03:45 PM
To probe a dynamic reentrant VI, you need to do it in the specific clone. The easiest way is place a breakpoint somewhere in the VI before you start running (preferably in the beginning). Then, when you run, the BP will cause the BD of the specific clone to open, allowing you to probe it.
I would also suggest creating an indicator out of the array wire and seeing what that shows. I actually wouldn't be surprised if that caused the issue to disappear.
So far it sounds like a bug based on your description.
02-01-2012 03:45 PM
Sure enough, a constant of 999 instead of the channel selector will also produce the weird behavior (There's only 105 channels available).
Blog for (mostly LabVIEW) programmers: Tips And Tricks
02-01-2012 03:50 PM
If I take the value sent to the indicator and cast it to a hex string, I get 16 chars: "0000 0000 0000 0000".
That sure looks like a zero to me, but the indicator is showing "4".
Blog for (mostly LabVIEW) programmers: Tips And Tricks
02-01-2012 04:03 PM
I would also suggest creating an indicator out of the array wire and seeing what that shows. I actually wouldn't be surprised if that caused the issue to disappear.
Not sure why that wouldn't be surprising. It would surprise me.
But anyway, it doesn't change anything.
I CREATED INDICATOR from the wire, and set its value to "5". When I run, it stays 5.
I changed it to I32, not DBL, and no change.
the fact that a cast to a string shows 0000 0000 0000 0000 (even when I started the string out as something else) says that data is getting there.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
02-01-2012 05:06 PM - edited 02-01-2012 05:07 PM
TEST CASE:
Attached is a simple VI that illustrates the misbehavior.
Run the REENTRANT CALLER, as is.
It works fine, REENTRANT or not.
Stop it.
Open the subVI, set the value of the selector to NONE , and MAKE DEFAULT.
Then set the indicator to 12345 or something and close the VI.
Then run the caller again.
NOW, if you run it REENTRANTly, the SELECTOR shows NONE, but the VALUE shows the 12345. After you select a LIVE channel, it all works.
Here's a JING to show it: http://screencast.com/t/LLjqtDlGV7X
It looks like if the first-time INDEX is out of bounds, you get this behavior.
Again this is LV 2010.0
Blog for (mostly LabVIEW) programmers: Tips And Tricks
02-02-2012 03:14 AM
I ran your example in 2011 and it works correctly - I go into the subVI, set the selector to none and make it default, set the indicator to something, then run the caller VI with the switch set to reentrant and I immediately see none and 0. That would seem to indicate that this is a bug in 2010.
You could try forcing an update of the display by using a property node for setting the value or after it or by defering and undefering updates on the panel and see if that helps.
02-02-2012 05:46 AM
In your Jing you didn't change the default value of the indicator, that's why it defaults to 0 when you switch back to <none>. The 12345 is an effect of being in memory.
02-02-2012 06:39 AM
In your Jing you didn't change the default value of the indicator, that's why it defaults to 0 when you switch back to <none>.
I understand that - that's the expected behavior. The question is why does it NOT go to zero when the selector starts out at -1.
It seems to be that starting out OUT OF BOUNDS (meaning < 0 or >= N) triggers the faulty behavior.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
02-02-2012 06:52 AM - edited 02-02-2012 06:54 AM
Tst - that's also confirmed here. Since the test case has no hardware calls, I can run it on a VM with LV2011 on it, and it works fine. Didn't have time to do that yesterday.
The same program fails in LV 2010. It's the same old story:
Patient: "Doctor, it hurts when I do this..."
Doctor: "Well, don't do that !"
Blog for (mostly LabVIEW) programmers: Tips And Tricks
02-02-2012 06:56 AM
Does anyone have LV2010 SP1 that can verify the (mis) behavior of the test case in message #15?
Blog for (mostly LabVIEW) programmers: Tips And Tricks