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

Hi all,

anyone good with expressions and loop type = custom?

 

Several lines of code can be eliminated if I can pull off the following:

 

I have a step that calls a C++ function, as a numeric test

this function fails the first time it is called somewhat reliably

this function will fail without a delay of 500ms between calls

Typically works second time called

 

so, using the looping tab, Pass 1  out of 3 tries works great, with record result of each iteration OFF, except I need a delay between each call, preferrably also located before the first call

 

any way to put that delay in the expressions?

 

 

Jeff

 

 

 

 

0 Kudos
Message 1 of 17
(7,586 Views)

Do you mean other than :

 

Insert Step > Synchronization > Delay  ?

 

Delay will be in seconds.

 

Is your loop inside TestStand?  If so, have you tried the above?

 

Maybe I didn't understand ...

0 Kudos
Message 2 of 17
(7,576 Views)

Well, yes and no

 

 

I could do

 x=0

while x<4

{

delay 300ms

send command / get result (dll call)

if result==0x50 break (no fail report)

x++ 

}

 

test result with fail reporting

 

or

 

single step with limits

     looping with pass / fail count

     do not record results of each iteration

The only problem is that i need a 300ms delay between the iteration of each dll call

 

doing it in a single step gets rid of 4 other steps

 

is this doable?

 

 

 

 

 

0 Kudos
Message 3 of 17
(7,571 Views)

I'm still a bit confused.

 

Can you post a screen capture of your code?

 

If the delay prevents you from having to run multiple iterations (ie 3) and then to look for at least one PASS result, then would it not be better to implement a delay?  Is the delay for the first run?

 

Where I am confused is here>  the iteration, is it for the voting / looking for a PASS result?  or is it iterating the test multiple times for some other variable?

0 Kudos
Message 4 of 17
(7,568 Views)

NOPE,

 

Each time the serial communications command runs, it requires a minimum 300ms delay before it can be run again

 

The looping PASS / FAIL in the step is ideal for this test, because it may need to be run 2 or 3 times to get it to communicate properly

However, the PASS / FAIL logic requires a delay of 300ms in between iterations of the loop

 

I am trying to put the delay and all of the logic into a single step

 

still need a screenshot

 

 

0 Kudos
Message 5 of 17
(7,556 Views)

I have a couple of ideas... Haven't really check them out...

Create a subsequence with the one step and a delay and set your looping on the sequence call to the subsequence...

or how about a SequenceFilePreStep or SequenceFilePostStep callback that has the delay...

0 Kudos
Message 6 of 17
(7,547 Views)

From reading your reply, you still describe that you are looping 2 or 3 times in order to be able to communicate properly and get a proper test result. 

If that's the case, then it is not a correct implementation.  You should implement a solution where the test only needs to run once.  Unless the requirement is to run the same test 3 times, which would be unusual.

 

Sorry to ask the same question again...

 

Other than trying to get a valid result, is there a requirement to run the test 3 times?  Or are you doing that as a workaround for the serial communication issue...

 

R

0 Kudos
Message 7 of 17
(7,522 Views)

I'd recommend doing what paul suggested and having a subsequence with a Wait Step and your dll call (you could even make it so that the wait only happens if the call fails), or, if you can modify your C++ code, just add a Sleep(500); statement at the beginning of your function. Ideally, it would be better to synchronize the communication with the device you are using rather than use waits, as it would avoid unnecessary waiting and speed up your sequence, however if that isn't possible, then the above are my suggestions.

 

 

Hope this helps,

-Doug

Message Edited by dug9000 on 09-09-2009 09:19 AM
0 Kudos
Message 8 of 17
(7,515 Views)

You are good: it's a known bug

after a reboot, the USB serial buffer may be filled with junk

 

I am using an existing piece of proprietary code, with a known issue (not developed by me or in NI, just to be clear:)

in this case, the previous step performed a reboot, and there is junk there

 

I am attempting to minimze the number of steps and complexity in the sequence

(ok, adding some complexity to this one step)

 

As far as wrong implementation, I would buy that except then why does NI teststand inherently support step looping until PASS or MAX COUNT to begin with? (all we are looking for is a step loop until PASS max count = 3 with a slight delay, record last result only)

  

You are advocating NEVER to use the loop until PASS functionality? when is the correct time? I thought this would be a good case for it

 

There are several ways to code this: We have already coded one of them; is there a better way?

 

  

 

Jeff 

 

 

 

 

0 Kudos
Message 9 of 17
(7,511 Views)

Hi Jeff,

 

I didn't realize that you were dealing with proprietary code..  Now I understand the workaround.  

I agree with the above suggestions.

 

Ideally you would want to clear the buffer before running.

 

The issue with voting or running a test until pass is that how can you tell when a test is meant to pass or to fail if a failure was detected.  I am thinking of UUT's that have intermettent failures and would slip the occasional PASS.  Also, it is more efficient to run a test once, especially if yo are doing datalogging.

 

I think the idea of "a loop until PASS or run 3 times and PASS if at least one pass was detecte" is for debugging purposes.  I would not recommend the approach as a production test.

 

R

0 Kudos
Message 10 of 17
(7,505 Views)