Testing at KIT: Wash list

[uellue]

• [x] Make Blobfinder PR for UDF parameter passthrough https://github.com/LiberTEM/LiberTEM-blobfinder/pull/42
• [x] Set header detail configuration resp. deal with missing header
  • A missing config value made the Dectris detector error out and send a different header than expected
  • The acquisition parameter for header details should be set to "basic" in the trigger function
• [ ] When running fast there were issues with missing headers that caused crashes. This should be handled gracefully by erroring out, not with a hard crash of the receiver.
  • Send dropped frame messages when skips in frame ID are detected
• [x] The base shape check has been patched out of the LiberTEM source code at KIT. Re-evaluate and fix root cause.
• [x] Display messages in case of errors for debuggability
• [ ] Documentation in libertem-rs repo: Libertem-dectris-rs requires additionally: cmake, clang, libclang, set LIBCLANG_PATH in case conda is used
• [x] Option to drain data from ZeroMQ based on series ID? One may receive data from a previous series if that was not consumed completely.
• [x] When cancelling the acquisition, the pipelined executor sometimes doesn't work for the next UDF run (might need a slight design change)
• [ ] Detctor status display widget would be really helpful

[sk1p]

Option to drain data from ZeroMQ based on series ID? One may receive data from a previous series if that was not consumed completely

At the beginning of the acquisition, this is now done, discarding messages that don't belong to the current series.

[sk1p]

Set header detail configuration resp. deal with missing header

This is done in #74 - streaming is enabled automatically and header_detail is set to 'basic' in both the active and the passive use case.

[sk1p]

Display messages in case of errors for debuggability

Logging can be enabled, which outputs debug information, not only for errors but also for other details, if the level is set to 'info' or 'debug'.

[sk1p]

When cancelling the acquisition, the pipelined executor sometimes doesn't work for the next UDF run

This should be fixed also, at least in LiberTEM v0.11 - the corresponding test case runs another UDF after the previous run_udf call err'd out. This now seems to work quite reliable.

The only thing where one has to take a bit care is the connection objects - if you create a new one without closing the previous one (for example, you re-run the notebook cell that connects to the detector system), you will still get issues. This needs to be properly documented, and we need to also provide plenty examples where this is properly handled.