The cause of this is due to the complicated internal object hierarchy for direct pulseblaster outputs. An internal IntermediateDevice and ClockLine are created for the pulseblaster direct outputs, but the IntermediateDevice subclass does not have it's own runviewer parsing class (as other intermediate devices do). Instead, the pulseblaster class calls the runviewer add_trace method for internally connected intermediate devices.
In order to fix this issue, and make the shutter code more robust, we should move the code for the shutters out of _load_device and into add_trace, thus ensuring that shutter markers can be calculated for any trace that is added (regardless of how it is added).
This may incur a performance penalty, since we will need to look up the open state on a per channel basis (which possibly requires traversing the connection table more than we currently do?), but since the load shot code is not performant anyway, I don't think it matters!
Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
The title says it all.
The cause of this is due to the complicated internal object hierarchy for direct pulseblaster outputs. An internal
IntermediateDevice
andClockLine
are created for the pulseblaster direct outputs, but theIntermediateDevice
subclass does not have it's own runviewer parsing class (as other intermediate devices do). Instead, the pulseblaster class calls the runvieweradd_trace
method for internally connected intermediate devices.In order to fix this issue, and make the shutter code more robust, we should move the code for the shutters out of
_load_device
and intoadd_trace
, thus ensuring that shutter markers can be calculated for any trace that is added (regardless of how it is added).This may incur a performance penalty, since we will need to look up the open state on a per channel basis (which possibly requires traversing the connection table more than we currently do?), but since the load shot code is not performant anyway, I don't think it matters!