Software/Hardware Trigger option for each device

[AhmetCanSolak]

FEATURE:

Is your feature request related to a problem? Please describe.

We are aware that we can use either software or hardware trigger for many devices of interest. Currently, we don't have a systematic way to address trigger source selection.

Describe the solution you'd like

I would propose having a base class property that chooses the trigger type and all device adapter implementations can use a unified API to adjust their behavior according to trigger type. This can also have a counter-part on GUI, where we can automatically show a trigger source field for devices.

Describe alternatives you've considered

Alternative could be having independent trigger source selection APIs for each device adaptor class but that would likely lead to inconsistencies.

This discussion might be related to #136 .

[edyoshikun]

I think this depends on how you want to drive the hardware that supports triggering, but I believe we might benefit from a property class that sets or retrieves information about the triggering so that this can be handled by a main timing controller. For a coordinated synchronized triggering, the timing controller needs information about the devices like the type of input/output (i.e digital, analog, voltage ranges), delays (i.e LC switching times, stage settling time, trigger response time, etc), and if the device is ready signals. It would be helpful to know these parameters to automate the sequence of pulses that should be generated.

However, from previous experience, having each device set to trigger mode has worked well considering most device types (i.e cameras, stages, mirrors, etc) have shared triggering functionalities. Since there is quite a lot of overlap between devices, there is also a benefit to having these properties implemented in the device abstract class, and perhaps, what has to be done is to ensure that the new devices that support triggering implement such functionality.