Checkbox use does not initiate GUI update when using "update_" and "apply_" functions

Hi.

Lately, I started to look into adding pulsing functionality to the Keithley 236 SMU driver and wanted to update it to the new “update_” and “apply_” scheme along the way. But it looks like checking the “Use pulse mode” checkbox does not initiate a GUI update.

excerpt from the code in use:

def update_gui_parameters(self, parameters):

         self.pulse = parameters.get("CheckPulse", False)
         
         # ... some other code here ...

         if self.pulse == True:
             new_parameters = {
             "SweepMode" : ["Voltage [V]", "Current [A]"],
             "Measuring Range": list(self.ranges.keys()),
             "CheckPulse": True,
             "PulseOnTime": 0.010,
            # ...some other code here ...
         }
         else:
             new_parameters = {
             "SweepMode" : ["Voltage [V]", "Current [A]"],
             "Measuring Range": list(self.ranges.keys()),
             "CheckPulse": False,
            # ...some other code here ...
         }

Can you confirm?

Christian

1 Like

The dynamic GUI updates have only been developed for parameters in the “Parameters:” Box (i.e. those that are defined in the driver but not always present in the module), which is commonly used in Logger or Switch.
As such, the “Use pulse mode” does not trigger a GUI update, as you have observed (but it’s not related to being a checkbox, but rather being a property that is already present in the SMU module itself).

I’m going to add this detail to the wiki, as it was missing before and also wasn’t clearly stated in the feature announcement.

1 Like

Hi Christian,

maybe you can explain what you aimed for and we can present a solution. So far, the pulse section of the SMU module comes with the most used parameters to configure a pulse measurement. Parameters that are not used are greyed out, so that the user can only configure those fields that are processed by the driver.

In the latest version of the SMU module, it has the capability to create a Parameter box to support parameters that are not provided by the fixed GUI fields. The idea is to stick with the fixed GUI fields whenever possible but provide special options whenever an instrument needs them.

Best, Axel

1 Like

Hello Axel.

I was adding the pulse capability when I read that the instruments demands the measuring range to be set manually if pulses are to be emitted, which in case of the K236 requires a selection that defines a current as well as a voltage range in combination.

Therefore, I used the new possibility to add this selection as a parameter but made the fallacy to think that I need to hide this if no pulsing is being selected. So I rewrote the driver to the new structure with dynamic GUI updates only to realize afterwards that setting the measurement range might be benefitial in ALL use cases, omitting the need to dynamically add or remove it from the GUI.

But now everything was already in the new structure, so I wanted to keep it that way, assuming that the checkbox for pulses can work the same way as other selections for initiating an GUI update.

But as this is not the case, I’ll just transfer the pulse additions to the original driver and leave it in the traditional structure regarding GUI readout.

Best wishes,
Christian

Hi Christian,

thanks for the update. For now, we will add a backlog item to expand the dynamic gui parameter to all fields.

In case you contribute the changes, we can have a look at it and might be able to provide further suggestions.

Thanks and best
Axel

1 Like

Hi Christian, dear all,

we have added general support for dynamic GUI parameters, i.e. they now also depend on other fixed GUI elements, and the options of fixed drop down boxes can now also depend on other GUI fields.

Before we merge and release these changes, we ask all of you to test it once.

We have added a self-extractable exe to the Download section of the SweepMe! account that you can extract by double click to any location.

When starting the SweepMe!.exe, this 1.5.7.7 beta will be loaded and all settings, scripts, and drivers will be loaded as usual.

We would like to collect any feedback whether your measurements work as expected, whether the UI updates correctly and whether you see any issue when loading and saving your settings (use a new file to save a test setting :slight_smile: )

If we don’t hear any complains we will release the new feature within the next version, probably mid to end November.

Thanks and best,
Axel

1 Like

Thanks Axel, we’ll run the tests soon. I think the Logger driver for the Keithley 194 is also a good testing ground as the appearing and disappearing of the trigger level value box depends on the selection of the trigger source to be set to “input signal” and this hasn’t worked so far without a reload of the driver.

1 Like

I tested it a bit with the Keithley 194 driver and looks it works as expected. Still, I wonder because this should have worked already beforehand as these are all fields within the Parameter box of the Logger module. New is that now changes of options in fixed GUI fields like in the SMU module will trigger a refresh of the parameters in the parameter box and vice versa.

1 Like

Hello Axel.

I once again mixed up the scope and the logger driver. It was in fact the scope driver that had the issue with the enabling and disabling of the trigger level setting when switching the trigger source from internal or external to one of the slope options and back. This is now working properly in the Beta, thanks!

Christian

1 Like