Neil Pate Posted June 16, 2017 Report Share Posted June 16, 2017 Hi All, I have recently discovered a subtle, but potentially disastrous, bug that can cause the Event Data Node to get confused as to the order of items which appear. I noticed this bug in LV2013 SP1 and have verified it still exists in LV2015 SP1. Please can somebody try recreate this on their system. I have not bothered installing 2016 and 2017 yet so cannot verify if the bug still exists. To recreate the bug: Open the attached VI. Notice the NewVal output is used. Also notice the Source element has been hidden. Add a new event, the Slide Value Change event to the existing Numeric value Change event. Notice the Source element is now present again and now OldVal is used ES Test.vi 1 Quote Link to comment
Antoine Chalons Posted June 16, 2017 Report Share Posted June 16, 2017 cool bug! I still have it in LV 2017 1 Quote Link to comment
Antoine Chalons Posted June 16, 2017 Report Share Posted June 16, 2017 (edited) I've tested with NXG 2.0 but I'm not sure I'm allowed to tell you that... it's not affected by this bug. ... arghhhh Edited June 16, 2017 by Antoine Chalons Quote Link to comment
Neil Pate Posted June 16, 2017 Author Report Share Posted June 16, 2017 (edited) The first rule of the beta is... ;-) Edited June 16, 2017 by Neil Pate Quote Link to comment
Neil Pate Posted June 16, 2017 Author Report Share Posted June 16, 2017 Thanks for confirming Antoine. I have filed a bug report (for LV2017). 1 Quote Link to comment
LogMAN Posted June 16, 2017 Report Share Posted June 16, 2017 2 hours ago, Neil Pate said: I have recently discovered a subtle, but potentially disastrous, bug that can cause the Event Data Node to get confused as to the order of items which appear. I noticed this bug in LV2013 SP1 and have verified it still exists in LV2015 SP1. Thanks for letting us know. I wasn't aware of that even though I tend to hide unnecessary event data, adding more events later. Now that I know about it Murphy's law will most likely cause a lot of my code to break during the next weeks I have tested your VI in LV2015 SP1 and can confirm that behavior as well. This bug happens actually as long as there are at least two values available before adding a new event: It is also not limited to the "New Value" data. It seems the node is connected via index (which as far as I know from VI scripting is how everything is connected). When a new event is added the original event data node gets restored and the index is not updated properly. However if all visible nodes are connected there is no issue: Surprisingly there is also no issue if the very first element is connected: My guess: LabVIEW only checks if the very first node is connected and for some reason assumes none of them is used, therefore decides to reset the node. Hope they provide a fix for LV2015 too Quote Link to comment
Neil Pate Posted June 16, 2017 Author Report Share Posted June 16, 2017 I have always actually disliked the fact that if you duplicate an event the IDE resets the Event Data Node to the full set. I have probably had this bug in the past but never actually noticed it. Quote Link to comment
LogMAN Posted June 16, 2017 Report Share Posted June 16, 2017 7 minutes ago, Neil Pate said: I have always actually disliked the fact that if you duplicate an event the IDE resets the Event Data Node to the full set. I have probably had this bug in the past but never actually noticed it. I don't remember them resetting when duplicating events. At least this is working fine in LV2015, so maybe it is specific to LV2013? Only when adding new events the nodes get reset, which is indeed quite annoying. Quote Link to comment
Neil Pate Posted June 18, 2017 Author Report Share Posted June 18, 2017 On 2017-6-16 at 6:34 PM, LogMAN said: I don't remember them resetting when duplicating events. At least this is working fine in LV2015, so maybe it is specific to LV2013? Only when adding new events the nodes get reset, which is indeed quite annoying. Hmmm, I cannot seem to recreate that behaviour either, but am pretty sure I have seen something similar. Quote Link to comment
LogMAN Posted June 18, 2017 Report Share Posted June 18, 2017 (edited) 2 hours ago, Neil Pate said: Hmmm, I cannot seem to recreate that behaviour either, but am pretty sure I have seen something similar. I have been playing around with this and found some interesting behavior. In the following VI I created a value changed event for a slide, duplicated it to another slide and finally to a numeric: As you can see the generated event differs depending on the type of the selected control: Duplicating events to a control of the same type retains the data node. Duplicating events to a control of different type resets the node. I wasn't able to reproduce your behavior because I generally put the control inside the event case that handles the Value Changed event. I only duplicate events which are of the same type or those which are working generically for example by connecting the CtlRef element, in which case I hide all other elements thus I don't get the bug. One more thing: If you duplicate an event without assigning a control right away (just confirm with OK) and later assign a control of the same type as the source event (a slide in my case), the node of the resulting event will be reset: Edited June 18, 2017 by LogMAN Quote Link to comment
MikaelH Posted June 18, 2017 Report Share Posted June 18, 2017 The bug is in 2016-64 as well. Also if you remove one event it also defaults back to default view. You seem to be safe if you never hide anything or if you hide all unwired terminals. BTW I've not seen the old bug where the node got disconnected from the frame lately, maybe at least they fixed that one. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.