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?
Solved! Go to Solution.
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 ...
Well, yes and no
I could do
send command / get result (dll call)
if result==0x50 break (no fail report)
test result with fail reporting
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?
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?
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
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...
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...
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,
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?
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.