Query on how to load my own written driver

[FateDecider]

Hi, Thank you for this excellent package. I have written a Driver class for my own Driver, as instructed on your Documentation. But, I do not understand how to load my custom Driver. Is it possible to include a short example in the official documentation? Thank you

[Python-simulation]

Hi!, there are currently three different versions of autolab. Depending on the version you're using, the procedure for loading a custom driver is different.

• For both the qchad41 GitHub (September 2020) and PyPi (March 2020) versions, the custom drivers folder is in the user folder in autolab/local_drivers. See the online doc https://autolab.readthedocs.io/en/latest/local_config.html. As for my version (December 2023), it is in autolab/drivers/local.
• Then to load the driver in the gui (as a Device) you need to add the driver informations to your devices_config.ini (or local_config.ini if you are using the PyPi version). It should look something like:

  [my_tunics]
  driver = yenista_TUNICS
  connection = VISA
  address = GPIB0::2::INSTR

  To see an example for your own driver, you can use this command:

  autolab.config_help('yenista_TUNICS')

  If you meant loading a device in a python script, then you can use this code to load a custom device:

  laserSource = autolab.get_device('my_tunics')

  To load a driver, it depends on the Autolab version, but in all of them this should work:

  laserSource = autolab.get_driver('yenista_TUNICS', 'VISA', address='GPIB0::12::INSTR')

  Hopes this informations help you!

[FateDecider]

Hi!, there are currently three different versions of autolab. Depending on the version you're using, the procedure for loading a custom driver is different.

• For both the qchad41 GitHub (September 2020) and PyPi (March 2020) versions, the custom drivers folder is in the user folder in autolab/local_drivers. See the online doc https://autolab.readthedocs.io/en/latest/local_config.html. As for my version (December 2023), it is in autolab/drivers/local.
• Then to load the driver in the gui (as a Device) you need to add the driver informations to your devices_config.ini (or local_config.ini if you are using the PyPi version). It should look something like:

[my_tunics]
driver = yenista_TUNICS
connection = VISA
address = GPIB0::2::INSTR

To see an example for your own driver, you can use this command:

autolab.config_help('yenista_TUNICS')

If you meant loading a device in a python script, then you can use this code to load a custom device:

laserSource = autolab.get_device('my_tunics')

To load a driver, it depends on the Autolab version, but in all of them this should work:

laserSource = autolab.get_driver('yenista_TUNICS', 'VISA', address='GPIB0::12::INSTR')

Hopes this informations help you!

Hi there, thanks for your reply. I separately figured out how to load newly written drivers. Does your latest package support the functionality - to save all data in continuous scan mode?

[Python-simulation]

Hi, currently it isn't possible but, a work around exists in all autolab versions.

Scan data are saved to a temp folder to be later moved where the user wants by clicking on the save button. By default the temp folder is created in %temp% (C:\Users\username\AppData\Local\Temp). So, you can always recover all the data saved during continuous scan, but with a naming convention that is not user friendly.

In my latest version, it is possible to change the temp folder location in autolab_config.ini, but you will still have a temp folder with a random name for each scan and default names for 'config.conf' and 'data.txt'.

I will think about a way to save all the scans. In the mean time, you can recover your data in %temp%.

[FateDecider]

I see, thanks. I am now trying your latest version, looks much nicer and more useful. Regarding my previous question, I think I can export the results of a 'continuous scan' to a csv, and that would give me all the curves. Is there a way to make saving automatic? To do that, we can write this as a utility function and import as an action in the recipe, correct?

[Python-simulation]

• If you have only 10 scans, you can save them each manually by selecting the scan id using the combobox on top of the scanner figure (with name 'scan_1') and then save it one at a time:

• If the sweep parameter and the measure step are from the same driver and you don't need to measure anything else during the scan, it could be better to have a function in your driver that does the sweep and store it in an array. That way, you can measure the array (representing your initial scan) in one step of a scan that has a dummy parameter with 10 points for the 10 'sweep'. That way you have one scan that contains your 10 'sweep' that you can save in one click:
  

[FateDecider]

I see, thank you for your prompt and helpful comments. Let me describe my ideal measurement recipe. I need to command a few devices (1. delay stage, 2. temperature controller, 3. lock-in amplifier, 4. translation stage) for my measurement.

For measuring a sample, I would like to 1) set sweep parameter as a variable defined in delay_stage driver 2) record Channel output (variable) on lock_in_amplifier driver 3) set a new position (variable) setting on translation_stage driver, and next repeat step 1 and 2 4) repeat steps 1-3 for two or more different positions - measure a total of N times. (For now, I have automated the data saving by doing the following on continuous scan mode: I have defined a function to save lock_in_amplifier's Channel output into a new csv - if the file exists, add +1 to the file index) 5) change the temperature on temperature_controller driver, repeat steps 1 -4 for each new temperature (this itself is another sweep parameter)

May you advise what is the most optimum way to do this? Preferably, I would like to automate all of these steps (including recording sweep parameters and data curves) in one configuration file. Happy holidays!

[Python-simulation]

• The best option is unfortunately not available yet, consisting of doing 2D scans or recipes in a recipe.
• The best alternative would be to write a script for your experiment instead of using the GUI, as shown in the doc.
• If you still want to use the GUI, you could mimic a recipe in a recipe by setting delay_stage, record Channel and set new translation_stage position multiple time in the same recipe to recreate a 'recipe'. The inconvenience with this method is that you can't easily change the number of sub-recipe and values, and you will have different variable names for each sub-parameter. If it's not clear, a picture may be more explicit:

[FateDecider]

Great, thanks for the detailed explanation. The GUI and the entire architecture of your latest version of autolab is something I really like and would hope to use more extensively, as a superior and more versatile substitute to LabView (I would also recommend this to my colleagues).

In my field of material characterization, a lot of scientific experiments would have (1) the sweep parameter and the measure variable to be on different instruments; (2) a series of plots with a common sweep parameter and a second dependent variable illustrated on a common legend. Since you have already implemented the option of specifying multiple recipes on your GUI, I envision there could be a direct way to do 2D scans and/or link multiple recipes.

As an example, I can describe how I envision my experiment could be written in your GUI: (1) Recipe 1 involves setting one position on translation_stage_driver, with delay_stage's variable as the sweep parameter. (2) Recipes 2, 3, etc would be setting different positions on translation_stage_driver, but with the lock-in amplifier Channel's output being recorded for all recipes. (3) The secondary sweep parameter (in my case, this would be temperature) would be an optional mode for users on the GUI that would repeat Recipes 1 to N for each value of the secondary sweep parameter. In terms of the GUI, this could probably be the overarching box that only 'lights up' once the user check some box.

P.S. If the user wants to sweep more external variables, they could do so on the same interface with different configuration files (another feature of the GUI that I like).

In most experiments, the need for (2) could be completely optional (in my case, this is for measuring multiple samples on a sample mount and I have an additional requirement of measuring the sample and reference back-to-back to minimize the effects of laser fluctuations) and may be generalized to other exploratory purposes (like setting only a few polarization values using a stepper motor, or switching on an external magnetic field). The main benefit of having multiple recipes would be to automate data acquisition.

It would also be nice to have an additional feature - how many times the individual recipes are repeatedly acquired. To save each curve, we can have an index variable that +1 if the data file already exists, for example:

As for plotting and analysis, the current interface looks excellent. If users have additional requirements, it would make more sense for them to do this separately on their custom script.

Again, thanks a lot for making extensive continuous improvements to this Python package! :)

[Python-simulation]

Thanks for your compliments and feedback, I'll take them into account for future features! You are also welcome to contribute to autolab as it a community driven project :)

[FateDecider]

Hi Sir, thank you for the very nice and elaborate updates over the past month. I have some functionality and misc questions. I am wondering where is the best place for this discussion that might help other users? Thank you for your time! :)

[Python-simulation]

Hi! I think discussions is the best place to discuss :) If you refer to the updates about multi-parameters, multi-recipes and recipe in recipe from the branch V2_candidate, I would really like your opinion on it!