Fix #34: Created EVS checkout test#53
Conversation
|
|
||
| # Check final command count has incremented by the number of commands sent | ||
| wait_check(f"<%= target_name %> CFE_EVS_HK COMMAND_COUNTER >= {cmd_count} + 21", 30) | ||
| wait_check(f"<%= target_name %> CFE_EVS_HK COMMAND_ERROR_COUNTER == 0", 1) |
There was a problem hiding this comment.
It was not established that the error counter was 0 at the onset of the test. Either compare this to the initial of error counter or remove this line.
There was a problem hiding this comment.
If you keep it, change this to a check() call and not a wait_check()
| set_line_delay(0.0) | ||
|
|
||
| # Check final command count has incremented by the number of commands sent | ||
| wait_check(f"<%= target_name %> CFE_EVS_HK COMMAND_COUNTER >= {cmd_count} + 21", 30) |
There was a problem hiding this comment.
Is a wait of 30 seconds needed here? The reset wait is 10 seconds. What behavior prompted this to be 30 seconds?
There was a problem hiding this comment.
Because it's a lot of commands, and they can't all execute simultaneously. I saw they definitely take more than one telemetry cycle. I reduced it from the standard 100 seconds, and kept a safe margin assuming 6hz telemetry. But I can experiment to see how much further it can be reliably reduced.
There was a problem hiding this comment.
No need. the 30 is better than 100 by far. With the command queueing that makes sense. Thanks.
There was a problem hiding this comment.
I set it to 12 seconds, then ran it 5 times in a row, and it succeeded every time. So that seems like a good baseline to use.
There was a problem hiding this comment.
For this app you said the rate was 6Hz? That tracks for 2 packets wait time I advised on the Issue text then. Glad that was able to come down. thanks for chaecking.
|
Note to self: This should be approved once we are able to merge to dev branch. Review complete |
2 participants
No description provided.