LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

wait function in loop (sorry I added wrong pictures first time I posted question )

I am trying to understand how the wait function works. When I make both wait in picture 1 1000ms the digital out stay on.  The digital out stay on (high) for ever.

 

Can someone tell me why these two Vis do not function the same?  I want to turn a DI out on for a specific time and off for a specific time.  

 

 

thanks...  I really apperciate it. 

Download All
0 Kudos
Message 1 of 10
(1,495 Views)

Hope this will help

--------------------------------------------------------------------------------------------------------
Kudos are always welcome if you got solution to some extent.

I need my difficulties because they are necessary to enjoy my success.
--Ranjeet
0 Kudos
Message 2 of 10
(1,457 Views)

Pix 2 is the correct one except that you write False in both sequences (so you're never actually switching the output...).

 

In Pix 1...the VI won't function because of data flow. Your sequence structure will set the output to true, wait 1000(ms) and then set the output to true and then immediately set it to false again. The wait outside of the sequence structure has no effect because it runs in parallel to the sequence structure. The way to make it work would be to set the wait outside of the sequence structure to be 2000ms. The wait will hold the execution in the current structure (e.g. while loop iteration, sequence section, for loop etc.) until it has elapsed.

 

You could also simplify as follows (every 1000ms invert the boolean):

2014-09-22_15-19-04.png


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 3 of 10
(1,454 Views)

Now just to complete the discussion , this piece from LabVIEW help ( to which people do not give much attention )

 

" Avoid using the Wait VI or Wait Until Next Multiple VI in parallel with other LabVIEW code, which can lead to unexpected timing behavior. Within a timed structure or a VI set to time-critical priority, only one thread is available, so the timing VI executes in sequence with the rest of the LabVIEW code despite being placed in parallel. In this case, LabVIEW serializes the parallel code paths while compiling the VI, and the execution order of the timing VI is subject to change from one compile to the next. On the other hand, when the code is not inside a timed structure or a time-critical VI, LabVIEW executes the timing VIs in parallel with the other LabVIEW code, which changes the effect of the timing VI."

0 Kudos
Message 4 of 10
(1,439 Views)

Ranjeet,

 

Thanks for the vi. It seem like both the Leds are coming on at the same time.  Is the correct?

 

Sam,

 

I have a state machine which i use the wait as method to avoid cpu using ton of CPU power when it waiting for signal. 

 

I was under the assumption in pix1 that the wait function would wait a total of 2000ms. The combine wait time. I did not know it would run in parallel.  I think that clears up why I was seeing what I am seeing. Thanks.

 

Do you have any suggestion for my state machine wait? It is only 5ms.

0 Kudos
Message 5 of 10
(1,426 Views)

I doubt both is happening at same time

--------------------------------------------------------------------------------------------------------
Kudos are always welcome if you got solution to some extent.

I need my difficulties because they are necessary to enjoy my success.
--Ranjeet
0 Kudos
Message 6 of 10
(1,419 Views)

Having some sort of execution timing (i.e. your 5ms wait in your state machine) is important to avoid hogging your CPU resources.

 

Without seeing your code for the state machine it's difficult to say what to do but... if you have the code that flashes the LED inside the state machine I would recommend having the state machine check the timing and toggle the LED that way. If you have that code in the state machine then you have to wait 2 seconds before you can move onto the next state.

 

I don't have time to provide an example but essentially you have a 'Toggle LED' state which checks a timer (e.g. using a shift register or the 'elapsed time' express VI) and if it has expired (time now - time LED last toggled > 1s) then toggle the LED. That way your state machine will continue to run at a higher rate and can respond to other actions (e.g. exit/stop) without having to wait too long.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 7 of 10
(1,411 Views)

@sticyfinger wrote:

I have a state machine which i use the wait as method to avoid cpu using ton of CPU power when it waiting for signal.


Wait a minute.  The code you showed earlier was in FPGA.  Is this question still in the FPGA realm?  If not, then you don't have to worry about CPU power.  FPGA is compiled in hardware.  There is no CPU.  That is part of the point of going with FPGA.


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 8 of 10
(1,394 Views)

The code run on the real time system.. VxWork.  

0 Kudos
Message 9 of 10
(1,297 Views)

@sticyfinger wrote:

I am trying to understand how the wait function works. When I make both wait in picture 1 1000ms the digital out stay on.  The digital out stay on (high) for ever.

 


Technically no, but it changes too fast for you to notice. Both waits wait in parallell, so it'll loop directly after setting the variable to False turning it into True again.

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 10 of 10
(1,268 Views)