LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event structure loop follows a process loop in Series. Can this lock the process loop updates to the front panel ?

Hi,

 

I have a "legacy" VI that I decided to update with an event structure loop after the processing is completed, sort of a post processing "state machine". 

 

The VI runs a process measurement in a loop and then ends.  This VI/loop section updates the front panel during processing, direct wiring to the graph and array indicator.

 

Then another loop, in series, begins, and it contains an event structure.

 

I have noticed that intermittently the graph and array indicator will not begin or maintain an update, at all.  It either always updates or never updates, it doesn't stop or start updating during processing.

 

Is it possible that somehow the event structure is not allowing UI updates even though it has not been "called" ?

 

***

 FWIW department:

1)The Event Structure doesn't use any "lock front panel" states.

2) If you click a button associated with an event case, during the first loop run, the VI has to wait for the processing loop to finish before responding.  This doesn't cause any failure of UI updates.

 

***

 

I'm thinking of putting the event structure in parallel, but that involves more overhead to coordinate, etc...

 

 

-------
Mark Ramsdale
-------
0 Kudos
Message 1 of 6
(2,440 Views)

A picture is worth a thousand words, and a VI worth even more.

 

It is impossible to visualize what your code is by your description.  Please attach a VI so we can see it.

0 Kudos
Message 2 of 6
(2,437 Views)

Hi,

 

Here is an overview of the concept I am interested in.  Is having an event structure in series with a leading while loop a possible candidate to cause the front panel to not update?

 

Event Loop in series.png

-------
Mark Ramsdale
-------
0 Kudos
Message 3 of 6
(2,420 Views)

An actual VI to look at would be better.

 

Do you have any front panel updates going on in the event structure loop?

 

The first while loop will run until whatever causes it to stop happens, then data flow dictates that it will move on to the event structure loop.  If any of those events have occurred before now, the event structure will start handling them.  If any events occur later, the event structure will wait until something happens then handle it.

 

Nothing will cause it to go back to your first while loop unless you ultimately end your Event structure while loop and have a master while loop around both to cause it to go back and repeat.  I definitely don't recommend that.

 

Without seeing real code, I can only guess at what you are actually doing.  It doesn't seem to me like you want to have two loops in series with each other.  You probably want to have two loops in parallel.  Look at producer/consumer architecture if you need to pass data or event information between one loop and the other.

0 Kudos
Message 4 of 6
(2,406 Views)

"Nothing will cause it to go back to your first while loop unless you ultimately end your Event structure while loop and have a master while loop around both to cause it to go back and repeat.  I definitely don't recommend that."

 

This is what I thought too.  Just to clarify more, I'm concerned about the case structure interfering with front panel updates in the first while loop during the time the first while loop itself is running, and due to data flow, the event structure portion of the code is not running.

 

The case structure has no cases where the front panel update is blocked.

 

*** 

 

I agree with what you have said about the events being queued up for the event structure.  I get what you are saying about a overall loop encompassing all the code.

 

The idea of running them both in parallel is intriguing, and complex too, due to the Domain issues for the users.

 

Sorry about the code, there is just a lot of SubVI's, obfuscation, and some NDA stuff too, I think the code would probably distract from the more general question about the event structure's possible involvement of my intermittent Front Panel update problem.

-------
Mark Ramsdale
-------
0 Kudos
Message 5 of 6
(2,403 Views)

Some follow up, I placed the event structure in a concurrent loop, rather than in series.  This seems to have resolved my front panel not updating problem.

 

So, result is two concurrent loops, one legacy loop running process, and another event structure loop to process user commands that are done "post process".  The alternative, building an event structure "into" a legacy loop, seemed to be more tactical that I wanted to go with the code. 

 

Since all the user process GUI interactions via the event structure are all 'post process', I disabled most of the buttons on the GUI until the legacy loop completes, this resolves any accidental button pushes that would clog up the event queue.


All the installed systems are no longer experiencing the front panel 'not updating anything'.

 

The weird twist is that the legacy loop also launches a subVI that shows it's front panel.  This front panel was also not showing up.  So the main VI front panel and the SubVI would not display, was very frustrating to "not see", but at least code was running and the tests and measurements were being performed.

 

Thanks for looking, not sure if this is totally related to the event structure, but changing the order of the data flow from series to concurrent worked for me.

-------
Mark Ramsdale
-------
0 Kudos
Message 6 of 6
(2,371 Views)