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.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Enum constant changing value at runtime LV 2011
Solved!
testingHotAir
Active Participant
05-02-2012 05:12 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hi all,
I have a program with a simple state machine which runs off a typedef enum constant. When I run the VI, the actual value passed out of the CONSTANT seems to revert to "0" randomly. Please see the two attached screenshots.
The only thing that definitely turns the bug on is connecting the enum wire to a selector (which I like to do to detect and handle errors). Nothing definitely turns the bug off 😞
This bug is almost identical to the one discussed in this thread here, which claims the bug was fixed in LV 8.0.1. I'm running 32-bit LV 11.0 on windows 7. Any idea how to kill this bug?
CLAD
Solved! Go to Solution.
Download All
Virus scan in progress. Please wait to download attachments.
Solution
Accepted by topic author testingHotAir
Darin.K
Trusted Enthusiast
05-02-2012 05:31 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Whenever I see things like this my first instinct is to drop an 'Always Copy' node following the constant.
elset191
Active Participant
05-02-2012 05:36 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
@testingHotAir wrote:
This bug is almost identical to the one discussed in this thread here, which claims the bug was fixed in LV 8.0.1. I'm running 32-bit LV 11.0 on windows 7. Any idea how to kill this bug?
In the lava thread referenced in the link you gave, it says disconnecting it from the typedef makes the bug go away. Is that true?
--
Tim Elsey
Certified LabVIEW Architect
Tim Elsey
Certified LabVIEW Architect
05-02-2012 05:52 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Disconnecting it from the typedef did not work for me, though I didn't disconnect all the instances on the diagram so that might be why. I really don't want to abandon typdef'd enums in my VIs....that would be a major nightmare.
I've never tried the Always Copy node....
I may have other problems though as the VI is now crashing labview every time I run it.
CLAD
05-03-2012 11:50 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Fixed the crashing issue; I was opening a reference to a VI in a packed library inside an in place element structure that was operating on a DVR of the class that owned the VI I was trying to reference.
Now my only bug is the enum one!
Putting Always Copy nodes after EVERY CONSTANT instance of my typedef does seem to solve the problem, but is extremely annoying.
CLAD
Ben
Knight of NI
05-03-2012 12:03 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Enums changing is a show-stopper for me.
If this bug is for real it is devistating.
Sanity check questions.
Q1:
Are you sure the value of the enum is changing (it goes to the wrong state) and not just the probe being bogus?
Q2:
Did you try to search on all instances of that enum and verify there are as many instances as are used in the code? I ask to rule the possiblity you have two type-defs that have the same number of entries but different definitions. It would be very hard to spot this issue if you are not looking for it.
Q3:
Does it act the same in an older version of LV?
Q4:
Do we have a CAR for this yet?
If this bug is real, I will be advising people NOT to use LV 2011. It sounds like it manifest itself as the LV equivilent of a "Goto Random" statement which would be bad.
Curious,
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
falkpl
Trusted Enthusiast
05-03-2012 12:08 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
"Goto Random" didnt see this on the ideas forum.
Has this bug been confirmed, I have some pressure to move to 2011 from 2010 and could use a reason to pospone this change.
Ben
Knight of NI
05-03-2012 12:13 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
@falkpl wrote:
"Goto Random" didnt see this on the ideas forum.
Has this bug been confirmed, I have some pressure to move to 2011 from 2010 and could use a reason to pospone this change.
I logged SR 1840861 to get some attention on this issue.
I am hoping this is something simple.
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Darin.K
Trusted Enthusiast
05-03-2012 12:29 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I have lobbied to get the icon of the Always Copy node changed to a Band Aid as I only use it to fix these crazy, that should not happen bugs. There are two types of problem I have seen which are fixed by this: improper buffer reuse for constants (what this appears to be), and cases where there is a bug in folded code that does not appear in normal code. Does changing to strict TD help? It shouldn't, but what kind of guarantee is that? 🙂
05-03-2012 12:55 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Ben,
A1: Yes, the VI goes to the wrong state when the probe shows the constant changing. Happens with no probe too.
A2: I searched all instances and verified that are only as many instances in the list as appear in the VI.
A3: I don't have access to an older version so I can't be sure.
A4: No CAR yet.
I agree on this being a show stopper. Hope it's just something I did! 🙂
CLAD
