LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Wait function problem

Highlighted

Hi everyone,

 

I am confused by wait function in LabVIEW. I have a while loop and the calculation time duration for each iteration is about 0.1ms without using wait funtion inside of the loop. However when I tried to add wait function and set the wait time to be 1ms, the average iteration duration became 5ms. Does it mean the iteration took 5ms to run each time? If it is the case, how did I get 0.1ms before using wait function? I also tried to add the wait time from 1 to10 and before 5 it gave me similar answer 5ms after 5 it give me the number I specified to it, so I think it works fine. I also attached my VI to it, I am using cRIO to run this VI so it wont work on the computer but the idea should be clear.

0 Kudos
Message 1 of 14
(1,410 Views)

Hello zzzfreedom,

 

Welcome to the forums!

 

I don't have the dependencies required to run the VI you provided, but I strongly suspect that the issue is that you have introduced a few controls and indicators in your for loop.  The default values in the VI you provided are all zero, so I'm not sure how many times you're running this loop, but keep in mind that those controls and indicators will be updated for each iteration of the loop.  This is unneccessary and introduces a big bottleneck.  There is never a *good* reason to update UI elements faster than 100 Hz, maximum. Replace those with constants or move them outside of the for loop, that'll give you a better idea of what the performance difference is.

 

Also as a general tip- when you post code, try and set the default values to something usable, include any subVIs or external libraries required for the code to run, and get rid of as much of the extra stuff that's going on as you can- all of those disabled diagrams make it unclear which specific code path you're trying to debug.

 

-edit-

If you're running this on an RT target there's no reason to update the UI at all- if you need to manipulate or use those values outside of this VI move the controls and indicators outside of the loop and configure the connector pane as needed.

 

Regards,

Tom L.
0 Kudos
Message 2 of 14
(1,397 Views)

Hi Tom,

 

Thanks for your reply, as you said I have many local variables in the for loop, however I need to update those variables during the test in order to do continues simulation and the speed is really a big issue for my test. I was using timed loop but it could not satisfied the speed I needed, so right now I am trying to see if while loop + wait function can do the same thing more efficiently. However the speed of VI is quite confusing me. the only value I assigned to the VI is the number of iterations I generally use 1000 or 10000 and the milliseconds to wait varies from 0-10. As I said if I dont have wait function it gives me 0.1ms iteration time, but the time increased to 5ms when i simply add wait function to it, even I set the milliseconds to wait time to be 0ms. I also tried to use wait until next multiple function, same thing happened as I use wait function.

 

I have attached the objective function to it, if you dont mind please help me further check what I did wrong here. The extension for the attachment is .out since the forum does not allow to post with it please modified it before using.

 

Best Regards

 

0 Kudos
Message 3 of 14
(1,383 Views)

Ah- I was actually referring to the control and indicator nodes you currently have connected to the index terminal and the wait function, not the local variables.  The "milliseconds to wait" and "millisecond timer value" control and indicator are new, yes?

 

Local variables are reasonably fast to update, although you should consider using shift registers instead where possible.

 

Regards.

Tom L.
0 Kudos
Message 4 of 14
(1,370 Views)

My bad, didnt see it clearly. However even I changed them, it doesnt make any differencesSmiley Sad

0 Kudos
Message 5 of 14
(1,360 Views)

OK First off lets introduce you to the concepts of arrays and a Shift Register:

Capture.PNG

First, those index constants are not required-  Hit Ctrl+h- hover over the array index and hit detailed help the default is for each element you grow to increments so, with no index contstants, you get elements 0, 1, 2, ...n.

 

Next, you only index them to feed them to indicator's local variables only to read them on the next iterationSmiley Surprised  a feedback node or shift register of type array of dbl would work so much better!  and, not require the UI Thread at all!  Really none of those controls or indicators are wired to the connector pane-  for debug use a probe!

 

Most of the rest of your indicators can go away too, replaced by Shift registers.  (If I infer correctly you might need to show two elements on "Target Disp" but I have no idea what that library function call is)

 

Essentially, you appear to trying to "C" your way into LabVIEW.  LabVIEW is a dataflow language-  hit the getting started material and online courses.

0 Kudos
Message 6 of 14
(1,323 Views)

Also, clean up the front panel and block diagram.  You have terminals on the BD and controls on the FP scattered to the far reaches of the window with too much empty space in between.

0 Kudos
Message 7 of 14
(1,312 Views)

Hi Jeff,

 

Thanks for your reply, basically this attached vi is only part of my code, and I would like to track the change of different variables on FP so I would like to have local variables inside of the loop instead of using shift register. The index constant is not necessary for sure, thanks for that info.

 

However even I have made all the indicators to the outside and changed the array stuff into shift register it still gives me the same result, which is about 5 ms when applying wait function but about 0.1 ms without using it. This is quite unusual, and similar to the speed when i was using timed loop (5ms). 

 

Also I am calling the objective function instead of using laview is because I would like to have easy maintenance for ppl not quite familiar with labview could understand the algorithm later on.

 

Thanks again for the reply and hope to hear from u again.

 

Best Regards


@JÞB wrote:

OK First off lets introduce you to the concepts of arrays and a Shift Register:

Capture.PNG

First, those index constants are not required-  Hit Ctrl+h- hover over the array index and hit detailed help the default is for each element you grow to increments so, with no index contstants, you get elements 0, 1, 2, ...n.

 

Next, you only index them to feed them to indicator's local variables only to read them on the next iterationSmiley Surprised  a feedback node or shift register of type array of dbl would work so much better!  and, not require the UI Thread at all!  Really none of those controls or indicators are wired to the connector pane-  for debug use a probe!

 

Most of the rest of your indicators can go away too, replaced by Shift registers.  (If I infer correctly you might need to show two elements on "Target Disp" but I have no idea what that library function call is)

 

Essentially, you appear to trying to "C" your way into LabVIEW.  LabVIEW is a dataflow language-  hit the getting started material and online courses.




0 Kudos
Message 8 of 14
(1,301 Views)
Hi RavensFan, 
thanks for the suggestion. It happens because I copy paste part of my code into this sample vi, I will modified the code.

@RavensFan wrote:

Also, clean up the front panel and block diagram.  You have terminals on the BD and controls on the FP scattered to the far reaches of the window with too much empty space in between.





0 Kudos
Message 9 of 14
(1,295 Views)

Hi Jeff,

 

Thanks for your reply, basically this attached vi is only part of my code, and I would like to track the change of different variables on FP so I would like to have local variables inside of the loop instead of using shift register. The index constant is not necessary for sure, thanks for that info.


Let me get this straight.

You have a loop you want to speed up to 0.1mSec /iteration and currently runs @5mSec

 

and you think tracking values inside the loop by writing to a local will help???  How fast are your eyes?  you "might" notice a flicker at 50mSec (2 orders of magnatude or 27dB SLOWER than your target speed)  cetrainly you'll never see and register multiple values updating at speed

 

Of course, its all the panel redraws that slow down the loop anyhow!  Think it through again.  For Proof of Concept, toss a defer panel updates method on either side of the benchmark code and watch the loop speed go up signifcantly

0 Kudos
Message 10 of 14
(1,266 Views)