@maltekliemann Sorry for the trouble this is causing…
Unfortunately, the API was not built to acknowledge the start of capture. Only the end of capture is acknowledged. You may have read though this before, but Mark highlights some details on this behavior here:
opened 04:32PM - 29 Mar 16 UTC
The "CAPTURE" command returns an ACK or NAK when the capture has completed. Howe… ver, the capture_start function does not wait for or read this reply, and there is no corresponding function to explicitly read it later. That means that at some point after the CAPTURE command is sent, the read buffer will receive an ACK or a NAK, but it will not be explicitly read as the reply to the capture command.
There are several problems with this:
1. The API was not set up to have multiple overlapping commands. Although this works in some cases, there is no way to identify which command originated an incoming ACK/NAK reply.
2. A future command that is waiting for a reply might pick up the ACK/NAK reply from the CAPTURE command.
3. The "IS_PROCESSING_COMPLETE" was not set up to work while a capture was in progress, it was designed to be used after a capture completed.
The "STOP_CAPTURE" command is an exception to this. There is special handling code in the Logic software to deal with this, and the "STOP_CAPTURE" command only works when there is a capture in progress. If a capture is in progress, the software will NOT reply with an ACK or NAK. It will NAK if there is no capture in progress. This is because the next expected response from the software is the ACK or NAK from the currently executing command. (this response is returned normally)
The correct capture flow should be:
issue "CAPTURE" or "CAPTURE_TO_FILE" command.
optionally end the capture with the "STOP_CAPTURE" command, but only if the original capture command has not returned yet.
wait for ACK/NAK response from software.
If ACK, then start polling "IS_PROCESSING_COMPLETE"
Note: even if you use the command "CAPTURE_TO_FILE" You must wait for "IS_PROCESSING_COMPLETE" before you start another capture or change any capture settings. This is because the "CAPTURE_TO_FILE" command is very basic, and was designed for saving only the capture tab.
If you are exporting and analyzer, and once "IS_PROCESSING_COMPLETE" has returned true, then you can start polling "IS_ANALYZER_COMPLETE"
Anyway, I think this could be causing other weird issues. For instance, when polling "IS_PROCESSING_COMPLETE" it might get an early ACK when then the capture finishes under the current process. However, then an extra NAK will show up in the buffer next, which will get interpreted as the response to the very next function. This could explain a lot of weird issues with this library.
The capture_start_and_wait_until_finished function has the same problem - it doesn't actually wait for the reply from the "CAPTURE" command, instead it calls the regular capture function and then polls the processing progress.
I think the right solution would be to add a wait_for_capture_finished function. After a start_capture call, all other functions should throw exceptions or otherwise be un-callable except for the new wait_for_capture_finished function and the stop_capture function.
The stop_capture and the wait_for_capture_finished function should both wait for the main capture command to ACK or NAK before returning. Then they should unlock the rest of the functions so they can be used again.
Unfortunately, I haven't had a chance to test this properly. If I'm missing something that does process the reply from the capture command, please let me know!
I’m also not familiar with a way to block until the capture is guaranteed to be running. This is likely not possible, though I’ll run this by the software team here in case there may be a workaround.