03-12-2024 11:40 PM
Good day, looking for a loop that would allow me to retest a step in my sequence, I came across this suggestion:
the detail is that when I put it in Loop Increment Description, it throws me this error:
replace the dot (.), before the RunState with (>) and I no longer throw the error. My question is: is that expression correct? Or how can I make that loop work?
In the same way, if you have any recommendations, I would like to take them into account.
Thanks.
03-13-2024 02:42 PM
The character between the "1" and "RunState" is a comma (,). The comma is a statement separator so TestStand will execute the "+=" first and then execute the "Wait" function call. If the output of the expression needs to return a value, TestStand passes whatever is returned from the last statement.
For example, the following expression would execute the two assignments and return 'True':
Locals.Num = 1, Locals.Str = "", True
03-13-2024 07:45 PM
Thanks for replying,
I tried using the comma (,), but the result was that I passed the test, expecting a 0xf0f as acceptable, I accepted all kinds of results as good examples (0x110f), it was like a force to pass to the step to which I added the loop, obviously it is not acceptable.
Could you give me a suggestion of a custom loop to do a retest or add a few more milliseconds to the test?
Thank you so much for replying.
Regards.
03-14-2024 08:57 AM
I have attached a TestStand 2019 sequence file has a multi numeric limit test that loops up to 20 times and the condition to pass is the loop index counter is 0x3.
I think the above reads better where you delay when evaluating the While expression and it only delays after the first loop. Here is it as text:
RunState.Execution.WaitForEndEx((RunState.LoopIndex > 1 && RunState.LoopNumPassed < 1) ? 5000 : 0),
RunState.LoopIndex < 20 && RunState.LoopNumPassed < 1
03-20-2024 07:59 PM
Best regards,
Thanks for the suggestion, unfortunately the test still passes as OK, even giving the wrong result. Attached image of the test:
These are my limits:
and my Data Source:
And the added loop was just as he suggested:
Again I ask for your suggestions to correct this problem, I remain open to suggestions, thank you very much in advance.
Regards.
03-21-2024 01:04 PM
Are you using the built-in Multiple Numeric Limit Test step type or is the step based off of a custom step type?
I ask because the image that you shared where it shows the "P" for passed does not look like a default step type. If the example step that I gave you is behaving as expected and the expressions you are using in your step are the same, then you might need to look at the step type that you are using.
03-24-2024 11:47 AM - edited 03-24-2024 12:14 PM
This is the info of my step:
The type of step is already stipulated by my client, he provided me with the sequence already done and I must respect the type of steps.
The only adjustments I can make are on it.
I want the loop because it presents me with false failures constantly, if the part that failed I try it on another equipment or after a moment I try it again it passes without problems.
The detail is that I haven't found the solution for this.
Best regards.
03-24-2024 11:58 AM
As an upgrade, I have 4 equipments. In one of them I used the loop that I show you below:
This loop worked for me, it only throws me real faults, the detail is that if I want to use it on the other 3 equipments, it throws me "Passed" the step even if I test a real failure.
Why is that? I don't know, practically all 4 teams are the same, but it only works for me on 1 only.
Do you have any thoughts on this?
Regards.
03-25-2024 10:12 AM
Relooking at your images again I see now that the image with the multiple tests is not a multi-numeric test step but are just steps in a sequence, yes? If that is the case, is the EBP States step just a Numeric Limit step type or a variation on it?
Some questions:
You are welcome to send a copy of the sequence with just the single step in it for me to look at it. You should be able to see my email address in my profile.