Closed clint-lawrence closed 3 months ago
I deleted a few comment and moved the content to #187
O.K. this is no longer draft...
I'm still not 100% on the address handler stuff. But my concerns are really how that ties with #182, so I think I need to get this merged and then see where that PR ends up. If we end up reworking the address handlers in that PR that is O.K.
I've also created a handful of smaller issues. Once this PR is reviewed and merged we can decide if we want to do any of that work before making a new release.
This introduces a new implementation of the jig switching support code. The primary motivation/goals:
This implementation make the "pin" concept the primary point of coupling between the AddressHandlers and VirtualMuxs. Then the JigDriver is being revised to improve type hinting of the jig driver object and also decouple instantiation at runtime from JigDriver subclass definition. In addition, I'm working towards the new code have complete (or near complete) type annotations.
While these changes are trying to avoid the need to change existing test scripts, it won't be possible to implement this in a completely backwards compatible way. So this will be introduced as a parallel implementation. Existing scripts will continue to run. New and updated scripts will import from a different submodule and be able to take advantage of the improved implementation. In time, the current jig_mapping implementation will be removed.
Once this work is done, it will be possible to move software with the related DriverManager change https://github.com/PyFixate/Fixate/pull/182/files
switch_through_all_signals
. Instead, create a method that returns all signals on a mux.iterate_all_mux_paths
to return mux object and signal pairs inline with the change above toswitch_through_all_signals
VirtualAddressMap.{update_pin_by_name,update_pins_by_name, __getitem__, __setitem__}
""
? In the previous jig_mapping implementation, the behaviour of the empty signal was hard coded. If you defined some pins against""
, I'm pretty sure that would be ignored. Should we check that the user script doesn't redefine""
?MuxGroup.force_trigger
or similar, that writes all the current mux states out to hardware, even if the pins haven't changed?MuxGroup.trigger()
orVirtualAddressMap.trigger()
that processes any pin changes inVirtualAddressMap._pending_updates
(Issues created #189 and #190)open()
method to address handlers that Jig Driver will call when it needs to. Make AddressHandlers accept a pin_list in init()RelayMatrixVirtualMux
calledBreakBeforeMakeMux
. (Issue created #191)MakeBeforeBreakMux
subclass ofVirtualMux
(Issue created #191)