LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event Structure exiting process working alongside a while loop sequentially.

Solved!
Go to solution

Hello, 

 

Perhaps the subject is not indicating much scope as to what I am trying to achieve. The LabVIEW GUI I have designed operates with an mbed application board.

 

I currently have an event structure which enables the user in the front panel to change the brightness of LED's using the controls. The GUI operates when the front panel is adjusted, however it always waits for event structure before making any updates on the hardware itself i.e. to the potentiometers (p19, p20). 

 

You may be asking why I even want to use an event structure - because when the program ends I wish to turn off all the LED's as an indication that the program has ended successfully.


What I wish to accomplish is for the while loop to continue reading and writing to the hardware without waiting for the event structure to occur, perhaps with the use of a timing sequence. The reason I want to do this is so that the pots can continually update in real time on the front panel. At the moment the LED's and potentiometers only update when the LED's are adjusted during the simulation, which is understandably due to the event structure.

 

However I was not sure as to whether or not the event structure could be time sequenced as a loop within a loop, that way the pots can continually be read and the LED's can still be written out. 

 

Not sure if I have made myself clear enough, so please let me know if you have any further questions and I will try to explain it a different way. 

 

Once you look at the GUI this may help put things into perspective.

 

Thanks!

0 Kudos
Message 1 of 5
(3,320 Views)
Solution
Accepted by topic author neunited

You can solve this by adding a timeout case to the Event Structure. This can be found under the Application heading. Wire a constant value to the top left hourglass in blue (from the outside). This is the timeout value in ms.

 

You can choose to either wire a small-ish number here, and have the timeout case be empty, or wire 0, and add a Wait in the timeout, or wire 0 and don't add a wait. In the last case, your CPU usage will hit 100% probably, so don't do that...

 

In either of the other cases, the value you wire is effectively the polling interval. Your indicators will be updated that often.

 

You might want to consider moving the Write inside the Value Change event. If you don't do this, then you'll need to wire the value array through the timeout case, or else zeros will be written (like in the stop case). It's your choice how to handle this, but if you add a timeout and keep the write where it is, you'll be writing every time you read too.


GCentral
0 Kudos
Message 2 of 5
(3,291 Views)

Thanks for that, really appreciate your help. 

 

One last question, would you know if some type of an array can be set up for the mbed-read.vi blocks. 

It would not let me achieve that by using a build array as I did for the LED's. So perhaps you would have some idea as to what block I should use for that? 

 

That way the design could be narrowed down instead of using an additional block for every pin on the hardware. 

 

Many Thanks! 

0 Kudos
Message 3 of 5
(3,280 Views)

I don't have the mbedRead function, so I can't see, and unfortunately it doesn't look like anything except a VISA Task is wired to them, so I can't guess what's going on.

 

It's possible that you could either place it in a For loop with an auto-indexed array of pin numbers (or make the subVI itself take an array, and then place the For loop inside).

 

If you mean the outputs, you could Bundle them into a cluster, but you'll have to Unbundle them outside to wire them to 2 separate gauges... I'm not sure if this is what you mean? An array would also work here with Build Array and Index Array, but you said you couldn't use that so maybe I'm misunderstanding?


GCentral
0 Kudos
Message 4 of 5
(3,269 Views)

I managed to solve the buffering problem as well by adding a short delay in the event structure. The program works nicely now with no buffering. 

 

Would be good to incorporate PWMOuts on the hardware now. 

 

Will look into that and post it when ready. 

 

Thanks!

0 Kudos
Message 5 of 5
(3,257 Views)