add support for Vortan Stradus Versa-Laser (light sources controller)

[carandraug]

@VroniPfann has a Vortan Versa-Laser and would like to add suppoort for it. This is controller device with up to 4 laser lines.

The device has a mini-USB port which enables control with Vortan's own software and does not reply to serial commands. Instead, it has a D-25 connector with the pins for RS-232. Alternatively, there is an optional control box that provides the typical D-9 connector for RS-232 communication.

[VroniPfann]

I wrote an initial implementation to add support for a Versa-Lase Vortran laser. The code can be found on my branch "vortran_laser". I also tested it on the hardware and it seems to be working fine. I would appreciate any feedback. Thanks!

[carandraug]

I have reviewed this now with @VroniPfann and with a Vortran Lase 8. Here's the notes from that:

• the commands print to stdout the answer from the device. If you want to do this, it should be done via the _logger (and probably with debug level)
• the default timeout is 6 seconds with means the device constructor alone takes >12 seconds (it calls readlines twice)
• when the laser is disabled, setting the power fails. This should work. The device should store the "wanted" laser power so that it emits that power when the laser is enabled later
• get status returns a bunch information from the device but if it's gonna return anything it should return any fault condition instead
• setting laser power to zero does not error but does not work either (I think it sets to the max laser power). This seems to be a bug on the device (should be reported to the vendor) so we need to find what is min laser power (I guess 0.1mW) and set it to that instead.
• we didn't test hardware triggers

[VroniPfann]

Hi @carandraug, just a quick question in order to test the hardware triggers I need to build up my controller, meaning I need to change the Triggertype from SOFTWARE to HIGH. You mentioned that this is possible through cockpit. How would you do that? Via a Pyshell from cockpit?

[iandobbie]

This is unfortunately not trivial as there are no GUI settings for the light sources, maybe there should be.

You will have to define a hardware trigger line in the cockpit depot .conf for that light source.

This is from the current documentation:

Digital hardware trigger configuration As well as these require components, any device with a digital hardware triggering also requires information about the trigger, eg:

triggerSource: dsp triggerLine: 8 In this instance the hardware trigger comes from the device named ‘dsp’ and utilises digital trigger line 8.

---

Then you will have to enable hardware trigger on the remote.....

This will involve getting a link to the remote pyro object and setting its trigger type. I outline how to do this below but I am not running a real remote so the exact syntax may be wrong, sorry.

1) Go to the PyShell window get the light object assuming name is 'Dummy 488', obviously change to real name. from cockpit import depot laser = depot.getDeviceWithName('Dummy 488')

2) get the microscope trigger types and modes. You need both as the trigger target mixin needs some complex combinations for cameras. from microscope import TriggerType, TriggerMode

3) set the remote trigger type. laser._proxy.set_trigger(TriggerType.RISING_EDGE, TiggerMode.ONCE)

Hope this helps.

[carandraug]

What Ian suggested will work if you want to test the whole thing from Cockpit. But what I said I when was there was to do setting of trigger type/mode from a python shell (no cockpit and no device server), and only used cockpit to set up a specific line high and low.

c = VersaLase(...)
l3 = c.devices['laser3']
l3.set_trigger(TriggerType.HIGH, TriggerMode.BULB)
l3.enable()

After this, there should be no light being emitted from the laser. After you set the line high on cockpit, then the laser should emit light.

[iandobbie]

We have discussed this point before but I think we do need a method in cockpit switch a generic triggered microscope device from software to hardware trigger mode.

For instance if you set a camera as hardware triggered in your depot.conf there is no way to then utilise a software trigger on this camera. Additionally by default the camera will probably start in software trigger mode as most devices seem to do that.

[carandraug]

We have discussed this point before but I think we do need a method in cockpit switch a generic triggered microscope device from software to hardware trigger mode.

For instance if you set a camera as hardware triggered in your depot.conf there is no way to then utilise a software trigger on this camera. Additionally by default the camera will probably start in software trigger mode as most devices seem to do that.

Yes, you're right. But that is unrelated to the issue here (adding support for the VersaLase on Python-Microscope). Let's open an issue on cockpit for it.

[iandobbie]

Probably best moved to cockpit so opened as https://github.com/MicronOxford/cockpit/issues/816

[VroniPfann]

Thanks a lot for your help David and Ian!

David and I have been in touch with the vendor and there seems to be no easy way of changing the laser power and the pulse mode (digital modulation) setting, while the laser is disabled. Thus, I have now implemented a workaround using two variables to track the laser power setting and the digital modulation state, while the laser is disabled. I also tested this on the device and it seems to work fine.

I have also started to implement a second workaround (commented out for now) as suggested by the vendor. This is the brief description: switching to analogue mode (EPC=1) first, enabling the laser then (as the input at this stage is 0V there is no light emitted), changing the laser power setting there (this works) and then switching the analogue mode off again, saves the laser power to this setting. It is also possible to switch on the digital modulation mode, while the analogue mode is on. However, the laser briefly emits light, when switching between those two modes. So, I was wondering what would be the better option and if it makes sense to integrate both workarounds? Should there be like a EPC hack on/off switch, depending on what the user wants to use?

I have pushed these changes to my "vortran_laser" branch. Any comments and feedback will be much appreciated!