LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running yet Broken VI?!?!?

Highlighted
This is less a question/bug, more of something mildly amusing that happened earlier today yeah, it's both broken, but the abort button is lit, I can tell you for a fact that that VI is/was running when the screenshot was taken, and there was no photoshopping done. I also have one of a VI that is running, broken with the red pause on the front panel, and on the block diagram I can't pause, or even step over/through/in anything. extra points for someone who can tell me what I did. (I already know)
Message 1 of 27
(2,082 Views)
Highlighted
It's a clone? Or better a Zombie?

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 2 of 27
(2,057 Views)
Highlighted

could be a clone.. (never heard of a zombie..  other than in some movies.. 😉 )

Under File Menu, select VI Properties, choose "Execution" for Category.  Within the Priority box, is it "subroutine"?

Or does the main vi call vi's that are set as subroutines?  Or are you calling vi's indirecty (dynamic code -- ie: executing vi's within given folder, etc)?

RayR



Message Edited by JoeLabView on 11-13-2007 07:41 AM
______________________________________________________________________
0 Kudos
Message 3 of 27
(2,032 Views)
Highlighted
It's actually a VI which is called from within a class, and uses a typedef that is in the class, but the VI is not in the class itself.  (The controls are just there for the ride, it's easier to make a copy of a class that has 'public' types that way)
 
When the VI runs, it makes the VI in the class that calls it broken, as it should, but in 8.2 at least, if any VI within a class is broken, all of the class is broken, including any typedefs, causing the VI using the typedef to break, but only because it is running. 
 
I had a good laugh yesterday when I came across that glitch.
 
Edit: The VI is being run on it's own, but in the end it will be called by the class.


Message Edited by Britoa on 11-13-2007 06:47 AM
0 Kudos
Message 4 of 27
(2,028 Views)
Highlighted

I can see how this might be amusing, but to others of us it is a little more concerning.  It looks like a bug to me.

Is it possible for you to post a simple project with just the necessary class(es) / typedef(s) / VI(s) to reproduce this "VI which is called from within a class, and uses a typedef that is in the class, but the VI is not in the class itself" problem?

0 Kudos
Message 5 of 27
(2,000 Views)
Highlighted
It could be a sub-vi, when the main vi runs, you can't run the sub-vi, because the sub-vi is controlled by the main vi, but you can stop the sub-vi.  The main vi must have a connection with the sub-vi.
------- LabVIEW 2009, So Easy, Even a Therapist Can Do It -------
0 Kudos
Message 6 of 27
(1,988 Views)
Highlighted
I just tried to create the bug in a simpler VI, and I can't seem to reproduce it.  I will try again later, on my next break.
0 Kudos
Message 7 of 27
(1,983 Views)
Highlighted
Alright, I managed to reproduce it.  It requires the following:
 
Parent class with a dynamic VI
Child class with an override of above dynamic VI, calling a VI not in the class
the child class must also contain a control/typedef, not of the private data.
 
the VI called by the child dynamic VI has to have the typedef in it.
 
To see the problem, just open the project and run untitled 2.vi  (it's just a while loop with a stop button)
 
 
This happens in 8.2, I am curious to know if it happens in 8.2.1 and/or 8.5
0 Kudos
Message 8 of 27
(1,973 Views)
Highlighted
I can confirm it happens in 8.5.
0 Kudos
Message 9 of 27
(1,967 Views)
Highlighted

Also confirmed in 8.2.1 ...



Message Edited by Steve.Briggs on 11-13-2007 01:40 PM
0 Kudos
Message 10 of 27
(1,945 Views)