LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does .vi only work every 3rd run?

I am running a .vi that consists of a state machine structure that is used with in my research group's analysis of electrical data.  Currently, my program locks up anytime my mouse leaves the .vi screen area and cannot be restarted succesfully without the following procedure:

 

1) Abort

2) Run

3) Abort

4) Run (It works this time)

 

I don't understand what can change from one run to the next, but it requires two program restarts after each freeze.

 

This is my first post to the forum, so please let me know if there are any standard bits of information I still need to provide.

 

Thanks,

 

Jeremy

0 Kudos
Message 1 of 9
(2,961 Views)

Are you using an event structure? 

 

Please post your code.

>

"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
0 Kudos
Message 2 of 9
(2,956 Views)

Yes, there is an event structure within the "No Event" state of my state machine.  I have one for uses related to a variety of minor buttons\sliders and another related to image processes.

 

I have attached the code for the main program.

 

0 Kudos
Message 3 of 9
(2,932 Views)

First of all, you have several event structures hidden inside case structures, which is a big no-no. Event structures will queue up event even if they are unreachable by dataflow. Even worse, since your events are set to lock the front panel until the event completes, an unreachable event structure will deadlock your VI forever if a related control is acidentally operated.

 

You need to seriously rearchtect your entire VI structure.

 

Your code also has high potential for race conditions. It is programmed like a text based code, with all controls and indicators disconnected, over-abusing local variables and property nodes everywhere else.

 

It is difficult to say much more, because I don't have IMAQ and you did not include any of the subVIs, typedefs, etc..

Message 4 of 9
(2,903 Views)

Thanks for the quick reply.  I have seemed to have fixed this problem, though it is only a bandaid i understand.  I have removed the "lock panel" from the event cases for now.  When we do a full rehaul or create new .vi's I will be sure to take your comments into consideration.  

 

On the note of an event case being called within a case structure, I have thrown a few probes on the wires with an event within the case structure, but they do not execute unless the case structure is such that the events are allowed to be called. This seem oposite from the comment that you made previously.  Do you have any thoughts as to why this is happening?

 

Thanks again for the help.

0 Kudos
Message 5 of 9
(2,863 Views)

@altenbach wrote:

First of all, you have several event structures hidden inside case structures, which is a big no-no. Event structures will queue up event even if they are unreachable by dataflow. Even worse, since your events are set to lock the front panel until the event completes, an unreachable event structure will deadlock your VI forever if a related control is acidentally operated.

 

You need to seriously rearchtect your entire VI structure.

 

Your code also has high potential for race conditions. It is programmed like a text based code, with all controls and indicators disconnected, over-abusing local variables and property nodes everywhere else.

 

It is difficult to say much more, because I don't have IMAQ and you did not include any of the subVIs, typedefs, etc..


I especially found the stacked sequence within a stacked sequence within a "State machine" [No- that is not a State machine Please look into the "Producer Consumer Loop (Events)" example from the example finder] That has 14 frames all using a read and write local to the (unwired) terminal "Save Array"  An Auto Indexing For Loop would reduce this "Save" code to postage stamp size

 

Can you explain what you were thinking when this snip was written?   (Silly Snippet tool changed the local to a P-node) 

 

WTH.png

 

If the file names are not equal move the file then write to the current filename?  Why is the flat sequence needed?

 

Just to be a little bit "Grumpier" You should always question a case structure with a boolean selector. 

WTH2.png

Why not use "...-1" and "0, default" cases and drive from the integer "Index of element"


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 9
(2,849 Views)

@JÞB wrote:

 Just to be a little bit "Grumpier" You should always question a case structure with a boolean selector. 

Why not use "...-1" and "0, default" cases and drive from the integer "Index of element"


Actually, the boolean case structure will run faster.  What should be there is a <0 instead of the =-1.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 9
(2,834 Views)

Wardjw0 wrote:

On the note of an event case being called within a case structure, I have thrown a few probes on the wires with an event within the case structure, but they do not execute unless the case structure is such that the events are allowed to be called. This seem oposite from the comment that you made previously.  Do you have any thoughts as to why this is happening?


You misunderstood me. If an event structure gets triggered, it queues up the event and locks the front panel until it has completed. It it is not reachable by dataflow (e.g. hidden in a different case structure or elsewhere), it will never complete and the front panel will be locked forever. Imagine you would hide an event structure with an event listening for a slide value changed that gets moved often. If the front panel does not get locked, it will queue up millions of events that can never get serviced, using more and more resources and gumming up your entire program after a while.

 

You need to ensure that an event structure is always ready to execute new events. This means it should never be inside a case structure or contain a lenghty operation.

0 Kudos
Message 8 of 9
(2,814 Views)

@crossrulz wrote:

@JÞB wrote:

 Just to be a little bit "Grumpier" You should always question a case structure with a boolean selector. 

Why not use "...-1" and "0, default" cases and drive from the integer "Index of element"


Actually, the boolean case structure will run faster.  What should be there is a <0 instead of the =-1.


I haven't done any recent benchmarks, but a numeric case with only two cases was equivalent in speed to a boolean case. A numer case only slows down (very slightly and for all practical purpose insignificant) if it has more than two cases. Did this change?

 

(I did extensive testing of this during the bit twiddling challenge back in 2002 (results))

0 Kudos
Message 9 of 9
(2,811 Views)