Copy an event structure containing local variables

[george.sterpu]

Hi

I'm designing a state machine in Labview and for the next state transition logic I need to wait for some buttons on the front panel to be clicked.

If i press a boolean button labeled from 1 to 9, next state should be X, otherwise (labels from 10 to 16) next state should be Y.

I thought the right approach for this would be an event structure, where I added two cases: case 1 (button 1: mouse down. button 2 mouse down, ..., button 9 mouse down) and case 2(button 10 mouse down, ...) . For each of these cases I'm reading & writing the local variable of some numeric double.

When i copy this event structure into another case of the exterior case structure, I notice the following: Every case in the event loop disappeared, and the local variable renamed automatically and points to a new created numeric indicator.

• How do I make an exact copy of the event structure, without the problems described above?
• Could you suggest a different approach, more efficient than mine?

Thanks for any answer.

[RavensFan · Accepted solution]

Start by reading Caveats and Recommendations when Using Events in LabVIEW - LabVIEW 2011 Help

The fact that you are trying to copy and event structure to another case, and that an event structure is going to be buried in a case to begin with tells me you are already heading down the wrong path and setting yourself up for a world of problems.  Your architecture will never seem to work right for you.

Event structures are always active and capturing events.  Even when the event structure is not in the path of execution, it is queueing up events that it has assigned to it.  If you have events that are set to lock the front panel until complete, then you are really screwed because an event structure will capture the event, lock the front panel, and the path of execution of your code through the state machine may never get to the particular case that captured the event to handle it then free up the front panel.

In general, you should have only one event structure in a VI, and it should not be buried in a case structure where it may never execute.  You also shouldn't have multiple event structures handle the same events.   These aren't hard and fast rules, but until you are completely familiar with how event structures work and completely understand the architecture of your code, you shouldn't violate them or you'll just be asking for trouble.

Likewise with using local variables.  The fact you say you have local variables and you are trying to copy them tells me you already have too many.  There is almost certainly a better way to build your VI that won't require local variables except in perhaps a few instances, and certainly won't need multiple event structures buried in case structures.

You should probably have a producer/consumer architecture that handles events.  Have a single loop with an event structure that captures all of your user interactions.  Pass the events to a consumer loop that is also your state machine by way of a queue.  (Also, known as a Queued State Machine or QSM).  Let the state machine determine how to handle the events it received based on what the current state of the VI is.

[george.sterpu]

I tested what you said about the event structure, and you're right 🙂 .

It queues up every event when it's not in the execution path, and it freezes the front panel when the lock option is active.

Though I consider this being unintuitive, more like a bug than a feature.

[RavensFan]

In my opinion, the Lock Front Panel should not be the default option, but there is logic to it.  It locks the front panel so you don't continuously queue up events that aren't going to be handled until much later.  Would you want a user queuing up dozens of button presses when the panel is not locked, but your program doesn't seem to be responding to them?  I wouldn't.

It is certainly not a bug.