support Toptica iChrome multi-laser engine

[carandraug]

Need to add support for Toptica Chrome multi-laser engines. used in our PALM-TIRF system for example.

[mickp]

One idea for this (and similar devices) involves a top-level device that exposes multiple subdevices over Pyro, e.g.

Toptica
  |
  |--405nm
  |--488nm,
  |...

This could be implemented with minor changes to the device server and base Device class.

• Add a method on the base Device that returns a map of names to instances. Subclasses may override this; the base class simply returns {self.name: self}.
• DeviceServer fetches the map of names to instances, and uses it to serve the instances on a single port.
  e.g.:
  PYRO:405nm@host:port
  PYRO:488nm@host:port

[carandraug]

I have been looking at this and experimenting with Pyros autoproxying.

I think we should avoid having each line as a separate device because they are not separate devices. We can't for example have two of them on at the same time, and we can't shutdown one without shutdown the whole engine. I'm thinking they should be some other class. It may make sense to have a Laser interface, something that non device class can also implement.

It would be nice if we could avoid mixing limitations of the device server on the device classes. I f we make use of autoproxying, after device creation we can register each of laser line instance with the pyro daemon. If we do this, a method of the device that would return the laser line instance will automatically return a Pyro proxy instead if being used via the device server. For example:

import Pyro4
import io

@Pyro4.expose
class LaserLine:
    def __init__(self, buf):
        self._buf = buf

    def content(self):
        return self._buf.getvalue()

@Pyro4.expose
class MultiLaserEngine:
    def __init__(self):
        self._buf = io.StringIO()
        self._line1 = LaserLine(self._buf)
        self._line2 = LaserLine(self._buf)
        self._buf.write('init 1\n')
        self._buf.write('init 2\n')

    def get_lines(self):
        return [self._line1, self._line2]

dev = MultiLaserEngine()
daemon = Pyro4.Daemon(port=37000, host='127.0.0.1')
daemon.register(dev, 'main-device')
for line in dev.get_lines():
    daemon.register(line)

daemon.requestLoop()

And on the client side:

>>> dev = Pyro4.Proxy('PYRO:main-device@127.0.0.1:37000')
>>> l = dev.get_lines()
>>> l[0].content()
'init 1\ninit 2\n'

[iandobbie]

Carnë Draug <notifications@github.com> writes:

I have been looking at this and experimenting with Pyros autoproxying. I think we should avoid having each line as a separate device because they are not separate devices. We can't for example have two of them on at the same time, and we can't shutdown one without

You can definitely have two lines on simultaneously. In the Toptica software anyway. Ian

[carandraug]

Ian Dobbie wrote:

Carnë Draug writes:

We can't for example have two of them
on at the same time

You can definitely have two lines on simultaneously. In the Toptica software anyway.

I read that there were four lasers but one output line and just assumed that there would only be only one laser emitting at a time. Makes sense that you could have all on the same line.

[mickp]

'One output' here means the combined beam, rather than four individual beams.

…

On Tue, 25 Jun 2019 at 23:03, Carnë Draug ***@***.***> wrote: Ian Dobbie wrote: Carnë Draug writes: We can't for example have two of them on at the same time You can definitely have two lines on simultaneously. In the Toptica software anyway. I read that there were four lasers but one output line and just assumed that there would only be only one laser emitting at a time. Makes sense that you could have all on the same line. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/MicronOxford/microscope/issues/71?email_source=notifications&email_token=ABHGTL26OYV4J37UZQLZUL3P4KIZ7A5CNFSM4HBYRES2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYRXH4A#issuecomment-505639920>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHGTLZRQL2TL2ZTNTFOSM3P4KIZ7ANCNFSM4HBYRESQ> .

--

________________________________ Mick Phillips

________________________________

[iandobbie]

I have implemented a toptica single laser device for the new 640 laser we have. Appears to work fine for the laser we have. Haven't done any work on the mock device or test suite.

pull from https://github.com/iandobbie/microscope/tree/toptica-laser

[iandobbie]

Turns out the MLE uses Scheme and not the simple text console of the iBeam laser. I will implement this as a separate class in the same module. Will do a bit of renaming too so don't pull the exisiting code yet.

[carandraug]

Implementing support for the multi-laser engine is delayed until we sort out an interface for this multi-devices device which we will try with the Prior ProScanIII (see issue #62). The reason is that we already have something for the Prior, and it mixes devices of different types (stages, filterwheel, and light sources) instead of only lasers as is the case with the iChrome MLE.

[carandraug]

Since version we have controller devices and we have multi line light sources such as the lumencor spectra and CollLED. Really the only issue left is actually doing the work of writing it and dealing with the Scheme interface (which hopefully won't be too hard).

[thtrummer]

There is an official Python SDK which can do the heavy lifting.

[carandraug]

@VroniPfann also needs support for the Toptica iChrome MLE.

[carandraug]

I wrote an initial implementation, without testing on real hardware, on my branch named "71-toptica-ichrome". I gave a quick look at the official Python SDK from toptica but our needs are so simple, it seemed simpler to do it ourselves.

Can someone with access to the hardware test the code?

[VroniPfann]

I have tested @carandraug code on our Toptica iChromeMLE. It only needed small fixes and seems to work fine now. I have uploaded them to my branch named "Toptica_iChromeMLE". There is still a bug that creates lasers that do not really exist, I try to fix that as well.

[carandraug]

Thanks for testing @VroniPfann. I have merged your changes, and added a check that a laser line does exist. I have rebased all changes into master and pushed. This will be part of the next release. Closing as fixed.