Python wrapper for AMDC doesn't always report full response from the AMDC

[Adonay4]

Summary

When using the Python AMDC wrapper with UART, I am encountering an issue where sometimes the amdc.cmd() function returns only a partial response from the AMDC. I think this is corresponding to when I am expecting a long response that possibly exceeds some internal timeout in the wrapper class, and so the class thinks that it has received the full response when in fact it has only received a partial response.

Is there a setting I could be adjusting to obtain the full response?

Details

I am completing the Profiling Tasks Tutorial. I am able to successfully interact with the AMDC via SDK's terminal:

Connected to COM6 at 115200
ctrl init
SUCCESS

ctrl deinit
SUCCESS

ctrl stats print
SUCCESS

Task Stats:
Loop Num:	130796 samples
Loop Min:	96.88 usec
Loop Max:	100.96 usec
Loop Mean:	100.00 usec
Loop Var:	0.00 usec
Run Num:	130797 samples
Run Min:	1.55 usec
Run Max:	2.00 usec
Run Mean:	1.69 usec
Run Var:	0.00 usec

However, when I try to repeat this in a Jupyter notebook, I run into some trouble with getting the response to ctrl stats print where I receive only part of the response:

If I then issue placeholder amdc.cmd(), the rest of the response prints out:

Analysis

It looks like what is happening is that the full response is transmitted from the AMDC to the PC. However, the amdc.cmd() function doesn't wait for the full response before displaying the data on the screen.

Is there something I can do to tell the AMDC class to wait longer for the rest of the data?

[npetersen2]

Thanks @Adonay4 for flagging this! This behavior is actually expected for this stats print command response.

The AMDC Python interface library waits (blocks) for the command response before returning from the python function call. Since the stats print message has many floating point values, it is actually "queued" up to print after the command ends. When the command runs, all it does is tell the AMDC to print the response later. Because of this, the command amdc.cmd() function does not capture the output, as you found.

Of course, once you know this, you can always call the amdc.cmd() function again after sleeping for a short time in the Python script to retrieve the data from the console.

[Known4225]

I have found another solution. The problem lies in the fact that calling ctrl stats print will output two instances of SUCCESS. One at the top right after the command is called, and another at the bottom after all of the output has been printed.

The python code waits until one of the key phrases is detected to stop listening:

# Only read until valid response!
valid_cmd_resp = ['SUCCESS', 'FAILURE', 'INVALID ARGUMENTS', 'INPUT TOO LONG', 'UNKNOWN CMD', 'UNKNOWN ERRROR']
for valid_resp_str in valid_cmd_resp:
    for line in output:
        if line.find(valid_resp_str) != -1:
            # Found a valid response!
            looking_for_cmd_resp_code = False
            break
    
    if not looking_for_cmd_resp_code:
        break

I don't know why python is able to still capture some of the output following the first SUCCESS, but this appears to be the case with UART sometimes (I have found with ethernet my output is terminated immediately after the printing of the first SUCCESS)

Nevertheless, the workaround is to have ctrl stats print return CMD_SUCCESS_QUIET instead of CMD_SUCCESS, which will suppress the first printing of SUCCESS. This solution worked for me, and I no longer have to call an empty command to capture the rest of the output.

[npetersen2]

Thanks @Known4225 ! I agree, this seems like the correct solution to get the stats printing to work with the python interface.