Parameter System Testing

[Jbsco]

This draft pull request includes Python scripts which can be used with COSMOS to test parameter system functionality, namely table validate and table update commands. A mock table is generated as a byte array, and various responses are scintillated by sending commands and checking the Software_Status_Packet that is returned.

[dinkelk]

Nice. There are probably other counts you want to reset too, like in the command router.

[dinkelk]

OK. To improve this pattern for more general use I suggest the following:

• Is there a wait-on-value directive in COSMOS? Ideally you would just be waiting for the condition that the command success count is == 2, or timeout if it does not reach that? Waiting for a time is brittle and artificially slow. This could be an issue when we want to start running tests as fast as possible with randomized inputs.
• We should wrap this logic into a function that does the following: 1) Check the current value of Command_Success_Count (and Command_Fail_Count too) and save them off 2) send command 3) wait for command success count to increment and return, or time out and check command fail count to see if it has incremented 4) return value of 0 for success, 1 for fail, 2 for timeout (or something like this).

[dinkelk]

Probably also want a function that does the opposite. If the former function was called wait_for_cmd_success we would also want one that is wait_for_cmd_failure

[Jbsco]

Is there a wait-on-value directive in COSMOS?

wait_check is similar to the check_formatted pattern, but adds a timeout argument. Switching to this eliminates the need for wait calls. Switched to wait_check in 9b73651.

We should wrap this logic into a function that does the following: [...]
Probably also want a function that does the opposite.

I will try to implement this in a future commit. check_exception allows for checking expressions expected to fail, although I think in all cases, if the API function call causes the script to stop then manual intervention is always required to resume or restart. This behavior may be different when not instrumenting each line.

[dinkelk]

What happens if check_formatted fails? Let's talk about this behavior.

[dinkelk]

Very cool that this works. But this is brittle in that your pattern here must match the parameter table or it will fail in hard-to-debug way. We should use the Adamant python autocoder to help here.

[dinkelk]

Would be really nice to import this direct from Adamant, instead of copying it here. Has that been tried?

[Jbsco]

This could be done by modifying the COSMOS compose file. Binding only the script directory and any needed utilities avoids issues with the COSMOS environment and symlinks in the broader Adamant environment. Something like this should work:

openc3-cosmos-script-runner-api:
  volumes:
    - "./../adamant_example/test/scripts:/plugins/DEFAULT/targets_modified"
    - "./../adamant/gnd/util:/plugins/DEFAULT/targets_modified"

Despite this, there still appear to be issues when trying to import the CRC utility. The script will appear in the Script Runner, and can be opened, but is unable to be imported as expected.