AutoMeasure Posted October 24, 2005 Report Share Posted October 24, 2005 This is a Labview 8 editing bug along the same lines as my previous post. I made it a new topic because it is a different VI attachment. Please read the note on the VI diagram. Thanks for trying it out. Download File:post-3297-1130164281.vi Quote Link to comment
tleibner Posted October 25, 2005 Report Share Posted October 25, 2005 This is a Labview 8 editing bug along the same lines as my previous post. I made it a new topic because it is a different VI attachment. Please read the note on the VI diagram. Thanks for trying it out. Another nice example of an anaomaly of the LV editor. I can reproduce you finding. Unexpected, too, if you delete the wire connecting the input tunnel of the TRUE case with the unbundle, signals sig.b. and ref.b remain valid without any data input. Well, the run arrow becomes broken. Further, deleting any wires from within the Loop structure will not cripple the Unbundle's signal names. I wonder what would be the LV developer's comment (Greg?). Thomas Quote Link to comment
Grampa_of_Oliva_n_Eden Posted October 25, 2005 Report Share Posted October 25, 2005 Another nice example of an anaomaly of the LV editor. I can reproduce you finding.Unexpected, too, if you delete the wire connecting the input tunnel of the TRUE case with the unbundle, signals sig.b. and ref.b remain valid without any data input. Well, the run arrow becomes broken. Further, deleting any wires from within the Loop structure will not cripple the Unbundle's signal names. I wonder what would be the LV developer's comment (Greg?). Thomas I brought both of these issues to NI's attention under service request # 734039. I will update if I learn more. Ben Quote Link to comment
Grampa_of_Oliva_n_Eden Posted October 28, 2005 Report Share Posted October 28, 2005 I brought both of these issues to NI's attention under service request # 734039.I will update if I learn more. Ben Confirmed by NI. A CAR will be filled. Ben Quote Link to comment
Grampa_of_Oliva_n_Eden Posted October 28, 2005 Report Share Posted October 28, 2005 Confirmed by NI.A CAR will be filled. Ben This should be the last update for now. The following quotes came from NI support. " I wanted to let you know that I filed that CAR for you -- it's already been passed to a developer. Thanks for keeping us on our toes! " and re:the CAR# "... it's 3QPET23Q." As far as I know this is the first confirmed bug for the released version of LV 8. So... Congratulations Joe for your shiny new CAR! Ben Quote Link to comment
AutoMeasure Posted March 17, 2006 Author Report Share Posted March 17, 2006 This bug was NOT fixed in Labview 8.0.1. Quote Link to comment
Jim Kring Posted March 19, 2006 Report Share Posted March 19, 2006 This bug was NOT fixed in Labview 8.0.1. Did you see this in the Release Notes? I couldn't find it. Maybe it wasn't considered significant. :headbang: Quote Link to comment
Travis H. Posted August 17, 2006 Report Share Posted August 17, 2006 This bug was NOT fixed in Labview 8.0.1. This was reported to R&D (# 3QPET23Q) and was fixed in LabVIEW 8.2. Note, NI was notified of this by AutoMeasure's post to the NI Monthly Bugs (October 2005) discussion forum post. Thanks! Travis H. LabVIEW R&D National Instruments Quote Link to comment
AutoMeasure Posted August 17, 2006 Author Report Share Posted August 17, 2006 This was reported to R&D (# 3QPET23Q) and was fixed in LabVIEW 8.2 ... I tried it in LV 8.2 and, yes, it's fixed. Great news!!! Thanks. That bug has given me trouble for several years. Quote Link to comment
jaegen Posted August 25, 2006 Report Share Posted August 25, 2006 I tried it in LV 8.2 and, yes, it's fixed. Great news!!! Thanks. That bug has given me trouble for several years. This is indeed wonderful news. We have been struggling with this (incredibly insidious and dangerous) bug for a long time, in a somewhat different form. It seemed to rear its ugly head whenever we edited a type def with a similar structure to your example - suddenly the unbundle was unbundling 10 identical signals, not ten separate signals that happened to have the same name but were inside 10 separate sub-clusters. This alone will likely move us to 8.20 sooner rather than later. Jaegen Quote Link to comment
Grampa_of_Oliva_n_Eden Posted August 25, 2006 Report Share Posted August 25, 2006 This is indeed wonderful news. We have been struggling with this (incredibly insidious and dangerous) bug for a long time, in a somewhat different form.It seemed to rear its ugly head whenever we edited a type def with a similar structure to your example - suddenly the unbundle was unbundling 10 identical signals, not ten separate signals that happened to have the same name but were inside 10 separate sub-clusters. This alone will likely move us to 8.20 sooner rather than later. Jaegen I agree and really hated this bug. This first tim eit hit it involved a cluster where I was limiting the history data loaded for a tag. Instead of loading the data for the last 24 hours, it loadd it FROMTHE BEGINNING OF TIME because istead bundling to the "start time" it was updating the Stop Time twice leaving the start time as 1904. For an application with 500+ VI that kept data from the time it was first started, this resulted in the application taking more time to boot each time it was started. It was only an error reported by VI Analyzer (Thank you Darren) that flaged my attention. At that time I attributed the error to myself. THe second time was a result of a customer calling my up after te4sting one of my changes and asking "BEN, did you even test this thing? It is displaying my RPM in the temperature field." Ben Quote Link to comment
jaegen Posted August 25, 2006 Report Share Posted August 25, 2006 ... It is displaying my RPM in the temperature field." Exactly. Mine is: "It's using my flow setpoint to control pressure!!" Yikes 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.