LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Wait Until Next ms Multiple.vi explanation

You are doing this way too complicated.

 

All you need is a single loop containing an event structure with a 2000ms timeout. In the timeout case you would toggle the booleans (use a shift register isntead of value property nodes!). Add a start event that sets the timeout from -1 (infinite) to 2000ms. Add a stop event, which will immediately break the timeout and stop the VI.

 

Most likely you can do everything using a single event case. (start, stop, timeout)

0 Kudos
Message 21 of 25
(901 Views)

See if this works for you.

 

0 Kudos
Message 22 of 25
(889 Views)

I myself found a idea of implementing waitms without using wait pallette.

We can just use a while loop with 2 TickCount palletes, one should be put outside and another one inside the loop where we find the differene in tick to be specific time.

This implementation will respond as soon as user presses button making sure that there is no delay between operation and user action.

 

For clarity on solution found, Have a look at the attachment.

 

 

0 Kudos
Message 23 of 25
(834 Views)

Thank you for producing a optimized solution. 

I was not knowing that we could configure multiple buttons in the same case which basically reduces number of event cases.

 

Thanks.

0 Kudos
Message 24 of 25
(827 Views)

shashiacharya113 wrote:

We can just use a while loop with 2 TickCount palletes, one should be put outside and another one inside the loop where we find the differene in tick to be specific time. 


The problem with this is that the loop will run as fast as the computer allows, grabbing as much CPU as it can possibly get and thus starving all other processes that are probably more important.

 

If the process cannot get enough CPU, e.g. because the computer is really busy doing other things it might skip one millisecond and then your loop will possibly never stop ever by itself (You definitely need to replace the "equal" comparison with a "greater or equal" to protect from this scenario.

 

Another problem is the fact that your time is defined as seconds, but the datatype is U32, that menas that even though the ticks have millisecond resolution, your control only has a resolution of whole seconds, probably not fine enough for typical work. You could never define a 0.5s wait, for example. Why not remove the x1000 and define the timecontrol in milliseconds, same as the regular wait?

0 Kudos
Message 25 of 25
(806 Views)