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
Ok, now onto teststand coding style:
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?)
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)?
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
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"
if it fails then add a delay of 100 ms.