NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Add a delay in a loop type test step

Solved!
Go to solution

I agree with clear the buffer, but I don't have a command to do that

I can, however send this commad twice as an action to clear the buffer, then send the third time and test the return

(I may be sending it 1 time too many on some boards, with a cost of 300ms, but I can live with that)

  

It's not as pretty, but it works

 

I assume that there is no way to embed a delay in the embedded step loop

 

Thanks All!

 

 

 

Ok, now onto teststand coding style:

 

Ray,

can you convince me that this loop to PASS functionality is for debug only?

After all, if I am in debug, I can select a step and loop on anything

 

In production use, I agree that the loop until pass will create LOTs of problems, and is a poor coding choice in general

Don't get me started on looping until it passes 5 times, hey there is something just wrong there

 

but, to syncronise, or flush a buffer, anything that is asynchonous in nature, It appears a valid choice to me, especially because it handles the error reporting gracefully, by just de selecting the record results for each iteration (anyone agree?)

 

 

Jeff

 

 

 

 

 

  

 

 

 

 

 

0 Kudos
Message 11 of 15
(2,377 Views)

LOL!!  😄

 

I'm not going to try to convince anything to anyone, as everyone is entitled to an opinion.. 😄

 

Sometimes we have to do unpretty coding as a workaround.  

 

There might be cases where the loop is necessary, such as the voting.  For instance, you have a data acquisition system which unfortunately acquires noisy signals.  You need to find some sort of signature within the signal and want to eliminate a fluke in the samples.  You would then proceed with a vote, which means running the test at least 3 times and seeing if the signature could be detected twice.  (ie: voteBetterThan >  (#samples/2) + 1  )

 

There might be some other situations.   If it was possible for you to implement the clear buffer of read once & discard the garbage communication within the software code, then I'd say that you should not use a loop to verify if there is a pass.

 

Your situation is a bit different and you are implementing it as a workaround.  Not the best scenario, but it gets you out of a bind..  It's a controlled implementation that works for you.  Let's keep it a that 😉

 

When you mention embedded code, are you referring to firmware?  or embedded software (ie: VxWorks, etc)?

 

R

0 Kudos
Message 12 of 15
(2,373 Views)
Solution
Accepted by topic author jeffh12345

Teststand allows you to do the same things many different ways

I agree most of them are not ideal, some are good, 1 or 2 ways optimal

 

 

By embedded, I was referring to the looping tab on the step

If you choose CUSTOM, then you can mess with the looping logic using expressions

I was originally trying to get a delay in the loop, everything in 1 step

 

 

 

jeff

 

 

 

Message 13 of 15
(2,369 Views)

I used a custom loop to add a delay if the step failed until I got a pass to continue

 

Add this code to the "Loop Increment Expression"

RunState.Execution.WaitForEndEx(RunState.LoopNumPassed==0?100:0)

if it fails then add a delay of 100 ms.loop.png

 

 

 

 

 

 

 

Message 14 of 15
(1,001 Views)

Finally somebody actually answered the OPs question!

0 Kudos
Message 15 of 15
(948 Views)