LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

why two parallel event structures affect each other

Solved!
Go to solution

I have a puzzle on the execution of two parallel event structures. See attached snapshot and vi.

The two two parallel event structures sit in two individual while loops. When event "mouse down" happens on numeric1, it will take 10s waiting in that case. Meawhile, if event "mouse down" happens on numeric2, there is no response until the first event structure "mouse down" case finishes.

 

This mechanism seems against the parallet running mechanism since the two while-even loops has no relationship.

Thanks.

 

WT

 

0 Kudos
Message 1 of 7
(2,833 Views)
Solution
Accepted by topic author weitong

@weitong wrote:

I have a puzzle on the execution of two parallel event structures. See attached snapshot and vi.

The two two parallel event structures sit in two individual while loops. When event "mouse down" happens on numeric1, it will take 10s waiting in that case. Meawhile, if event "mouse down" happens on numeric2, there is no response until the first event structure "mouse down" case finishes.

 

This mechanism seems against the parallet running mechanism since the two while-even loops has no relationship.

Thanks.

 

WT

 


What happening is perfecty correct as per the configuration. If you want to get what you expect, go to the 1st event structure "Edit Event" and uncheck the "Lock front panel" option.

-----

The best solution is the one you find it by yourself
Message 2 of 7
(2,819 Views)

While Anand is of course correct, you need to redesign your code from scratch. It is generally a bad idea to trap event structures with code that takes a long time to finish (long wait, intereactive while loop, etc). Just handle the event immediately and keep track of time if you want to discard certain events for a certain time interval. What good is an event structure if you tie it down with other stuff so it cannot react to events?

 

It also does not make sense to have a local variable in the upper loop. In fact you should combine the timeout and mouse down event, because they have the same code, right? No need for local variables. remove the internal wait. You should also use only a single stop button. Place a stop event case insode both event structure so both loop stop whren it is pressed.

Message 3 of 7
(2,792 Views)

Thanks to both of you.

 

The vi is only a demo of the question.

Actually, for the first event stucture,  I wish to track Liquid Helium level in a cryostat per 30 mins regularly at the timeout case. The mouse down event is only for the  purpose that one wish to know the current LHe level immediately.

 

The second event structure is to do some physical measurement (resistance, temperature) task with user's interaction.

 

WT

0 Kudos
Message 4 of 7
(2,772 Views)

@weitong wrote:

Actually, for the first event stucture,  I wish to track Liquid Helium level in a cryostat per 30 mins regularly at the timeout case. The mouse down event is only for the  purpose that one wish to know the current LHe level immediately.


Be very careful with that setup.  If an event happens, your timeout is reset.  So you can't really depend on the timeout case to consistantly time something.


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
Message 5 of 7
(2,730 Views)

Thanks, I got the idea.

 

WT

0 Kudos
Message 6 of 7
(2,705 Views)

But measuring the helium is a quick operation, right. It does not take as long as your demo events seem to imply.

 

If you want to keep the original timing of the timeout event, even if other events occur, you can manipulate the timeout so it maintains it's approximate phase. My old example from 2005 is described here.

0 Kudos
Message 7 of 7
(2,683 Views)