New DAQ_type? DAQ_Control?

[Ashwolaa]

I was thinking in some future applications in the context of acquisition and control of settings in the laboratory.

One tool that we are consistently using in my laboratory are the triggers. We receive a signal (that we commonly called trigger) which we use as a referenced clock to send delayed signals around the experiment. Each signal becomes a trigger to launch the acquisition, put up some voltages, fire some gas, etc ....

Usually, this requires instruments such as Digital Delay Generator which are used to control the different signals (type, amplitudes, relative delays, ...).

In the context of pymodaq, I feel like we are reaching the limits of the DAQ_move for this purpose. The current strategy for motors, was to create a DAQ_move for each axis however, here we are talking about possibly 10-20 entries.

According to this, I believe a more general DAQ should be more adapted like a DAQ_control or something in this line.
As a very sketchy layout, here is a first draft of what it could look like.

Initially, we only need something that displays a value and that we can change such as a typical DAQ_move. This would cover all basic needs as usually all entries from the same instrument share the same units.
Additionally, we can add custom made widgets/models for specific use. For example, in the context of the delay generator there would be many additional information such as ascending, descending, which channel to trigger from, etc .... This can be added as a set of QCombobox / QCheckbox / .... .
The finality would be to allow any user to easily add this kind of widgets just from his plugin.
For example, this could then easily be implemented by adding an additional dictionary in the preamble:
custom_widgets = {"my_checkbox_widget": dict(type =QCheckbox, status=True) , "my_QCombobox_widget": dict(type = QCombobox, items=['Ascending'/'Descending'])

In the initialization, each widget's signal (according to its type) would be connected to an extra emit signal when it changes value such that the user can easily catch it to change the parameters in his instrument. Additionaly, we could also just add a new function which collect changes from these custom widgets just as what we currently using in the parametertree settings.

Overall, this approach would add a lot of flexibility for the user and could extend the framework of the DAQ_move to a broader range of instruments.

We are in the direction of reducing the impact of the GUI which was nice as a start up and for individual control but is quite overwhelming in the context of actual lab measurements. The new interface reducing the DAQ_move goes in a similar direction and I feel like this new DAQ follows this path.

[TheFermiSea]

I love this idea! I've been hacking together my own plugins and custom extensions, and while PyMoDAQ is absolutely fantastic, I keep running into the same issue - we're stuck with just DAQ_Move and DAQ_Viewer as our base control modules. This works great for simple setups, but when you're dealing with more complex instruments that need to do both actuation AND detection (think scanning probe microscopes, or laser systems with built-in power monitoring), you end up having to create multiple modules or do weird workarounds.

I've been playing around with the idea of a decorator-based factory that could auto-generate PyMoDAQ controllers from simple instrument drivers. Imagine being able to just decorate your existing hardware drivers and magically get a fully functional PyMoDAQ plugin!

The Decorator Approach

Here's what I'm thinking - you'd have decorators that tell the factory how to wire up your methods to PyMoDAQ's parameter system:

def pymodaq_parameter(param_type: str, title: str = None, **kwargs):
    """Mark a method as a PyMoDAQ parameter (shows up in the settings tree)"""
    def decorator(func):
        func.__pymodaq_param__ = {
            'type': param_type, 
            'title': title or func.__name__.replace('_', ' ').title(), 
            **kwargs
        }
        return func
    return decorator

def pymodaq_action(title: str = None, label: str = None, **kwargs):
    """Mark a method as a PyMoDAQ action (becomes a button in the UI)"""
    def decorator(func):
        func.__pymodaq_action__ = {
            'title': title or func.__name__.replace('_', ' ').title(), 
            'label': label or func.__name__.replace('_', ' ').title(), 
            **kwargs
        }
        return func
    return decorator

def pymodaq_readout(title: str = None, refreshable: bool = True, **kwargs):
    """Mark a method as a data readout (gets called during acquisition)"""
    def decorator(func):
        func.__pymodaq_readout__ = {
            'title': title or func.__name__.replace('_', ' ').title(), 
            'refreshable': refreshable, 
            **kwargs
        }
        return func
    return decorator

Your Instrument Driver Gets Super Simple

Instead of inheriting from DAQ_Move_base or DAQ_Viewer_base and implementing all those PyMoDAQ-specific methods, you'd just write a clean driver and sprinkle in some decorators:

class MyLaserController:
    """Just a normal instrument driver with PyMoDAQ decorators"""
    
    def __init__(self, port='COM1'):
        self._power = 0.0
        self._temperature = 25.0
        self._is_on = False
        # Your normal initialization here

    @pymodaq_parameter('float', title='Power Setpoint (mW)', limits=(0, 100))
    def set_power(self, power: float):
        """This becomes a parameter in the PyMoDAQ settings tree"""
        self._power = power
        # Actually send command to hardware here
        self.send_command(f"POW {power}")

    @pymodaq_readout(title='Actual Power (mW)', refreshable=True)
    def read_power(self) -> float:
        """This gets called during data acquisition"""
        # Read from hardware and return the value
        return self.query_float("POW?")

    @pymodaq_readout(title='Laser Temperature (°C)', refreshable=True)
    def read_temperature(self) -> float:
        """Another readout that shows up in the data stream"""
        return self.query_float("TEMP?")

    @pymodaq_action(label='Turn On Laser')
    def enable_output(self):
        """This becomes a button in the PyMoDAQ interface"""
        self._is_on = True
        self.send_command("OUTPUT ON")

    @pymodaq_action(label='Turn Off Laser')
    def disable_output(self):
        """Another button"""
        self._is_on = False
        self.send_command("OUTPUT OFF")

    def close(self):
        """Normal cleanup - no decorator needed"""
        self.disable_output()
        self.disconnect()

The Magic Factory Function

This is where things get interesting. The factory would introspect your decorated class and automatically generate all the PyMoDAQ boilerplate:

def create_pymodaq_controller(driver_class, name=None):
    """Auto-generate a PyMoDAQ controller from a decorated driver"""
    
    if name is None:
        name = f"DAQ_{driver_class.__name__}"

    # Start building the PyMoDAQ controller class
    controller_dict = {
        '__instrument_driver__': driver_class,
        'controller': None,
        'params': [],  # Will be auto-generated from decorators
    }

    # Scan the driver class for decorated methods
    # Build the params list automatically
    # Generate ini_instrument, close, value_changed methods
    # Wire up the data emission for readout methods
    # Connect action methods to the GUI

    def ini_instrument(self):
        """Auto-generated initialization"""
        self.controller = self.__instrument_driver__(self.params['connection_params']['port'])
        # Set up any parameter-specific initialization
        self.status.initialized = True
        self.status.controller = self.controller
        self.emit_status(ThreadCommand('Update_Status', ['Instrument initialized']))

    def value_changed(self, param):
        """Auto-generated parameter change handler"""
        # Find the decorated method that corresponds to this parameter
        # Call it with the new value
        # Handle any exceptions and emit status updates
        super().value_changed(param)

    def grab_data(self):
        """Auto-generated data acquisition"""
        data_list = []
        # Call all the @pymodaq_readout methods
        # Package the results into PyMoDAQ data format
        self.data_grabed_signal.emit([DataFromPlugins(name=self.title, data=data_list)])

    # Build the complete controller class
    controller_dict.update({
        'ini_instrument': ini_instrument,
        'value_changed': value_changed, 
        'grab_data': grab_data,
        # ... other auto-generated methods
    })

    # Return a proper PyMoDAQ controller class
    return type(name, (DAQ_Controller_base,), controller_dict)

Just One Line to Create Your Plugin

# That's it! You now have a full PyMoDAQ plugin
DAQ_MyLaser = create_pymodaq_controller(MyLaserController)

Why This Could Be Game-Changing

The beauty of this approach is that you separate the "talking to hardware" part from the "integrating with PyMoDAQ" part. Your instrument drivers become these clean, testable classes that don't know anything about Qt signals or parameter trees or data emission. The factory handles all the PyMoDAQ-specific glue code automatically.

This could also solve the DAQ_Move vs DAQ_Viewer limitation. The factory could look at your decorators and figure out "oh, this class has both parameters AND readouts, so I'll make it emit data AND show up in the scanner's actuator list".

Plus, if someone already has a working instrument driver, they just need to add a few decorators and boom - instant PyMoDAQ plugin. No more copy-pasting from templates or trying to figure out which base class to inherit from.

What Do You Think?

I'm curious what the PyMoDAQ community thinks about this approach. Would something like this be useful? Are there patterns in the existing codebase that could support this kind of factory? What other decorator types would be helpful?

Obviously this is just a rough sketch and would need a lot more work to handle things like the parameter tree structure, proper data formatting, error handling, the ini_instrument sequence, etc. But the core idea of using decorators to auto-generate PyMoDAQ controllers feels like it could really streamline plugin development.

Has anyone else been thinking along these lines? Or am I missing something obvious about why the current two-module approach is actually better?

This is totally just brainstorming at this point, but I'd love to hear what folks think!

[Ashwolaa]

Are you coming to the Pymodays in Montpellier??

[seb5g]

@TheFermiSea is actually in Texas but will attend the round table about AI. However that could definitely be a subject for discussion. I'm not sure if we'll gain for that. For once, I think driver development should be done most of all in dedicated framework, for instance pymeasure and then just import this controller into pymodaq. But because you cannot modify the code base of pymeasure to incorporate decorator or pymodaq stuff, then you'll have to write the intermediate layer.

On the same line of thought but different topic: I was discussing with other people (@BenediktBurger ) about defining some base class or traits an instrument would have and from which we could automate discussion and even instrument plugin auto-generation. But then what traits should be put forth... That was what trigger the creation of the issue:
pymeasure/pymeasure#825

but no one went beyond that...