ASI controller stage settings

[iandobbie]

So with the updated info where we are now reading the info output most of this isnt working on my MS200 (very old). If I connect to cockpit, grab the device and call get_all_settings:

s=depot.getDeviceWithName('stage')
s._proxy.get_all_settings()

This geenrate a flod of errors in microscope.....

2023-10-27 15:32:56,519:ASIMS2000 (microscope.abc):ERROR:PID 83380: getting Axis Name X: ASI controller error: :N-1
2023-10-27 15:32:56,583:ASIMS2000 (microscope.abc):ERROR:PID 83380: getting Limits Status X: ASI controller error: :N-1
2023-10-27 15:32:56,696:ASIMS2000 (microscope.abc):ERROR:PID 83380: getting In_Dev Sign X: ASI controller error: :N-1
2023-10-27 15:32:56,888:ASIMS2000 (microscope.abc):ERROR:PID 83380: getting Ramp Time X: ASI controller error: :N-1

And returns a basically empty settings dict...

{'Axis Name X': None, 'Limits Status X': None, 'Input Device X': '2', 'In_Dev Sign X': None, 'Max Lim X': 158.0101, 'Min Lim X': '-61.989920', 'Ramp Time X': None, 'Max Ramp Stps X': None, 'Run Speed X': None, 'vmax_enc X': None, 'Servo Lp Time X': None, 'Ramp Length X': None, 'dv_enc X': None, 'LL Axis ID X': None, 'Drift Error X': None, 'enc_drift_err X': None, 'Finish Error X': None, 

Both outputs are truncated...

[juliomateoslangerak]

I looked into this and there are a few issues involved. My testing was lousy.

1- The getter and setter functions were not taking into account the return values where readonly. This is fixed.

2- The answers provided by the controller are not consistent. The "standard" answer for a getter is :A X=value where A seems to be the OK and X is the axis. However:

• many settings return :X=value A
• some other return :A X=value A
• some other return :A value. In my case only one, so I'm getting it with a if statement.
  I implemented exceptions to all cases and I hope there are no more. This seems like a change in the interface that has been unconsistently evolving.

3- Looking again to the return of the INFO command in @iandobbie controller I realized that the order of the command and the units is reversed compared to my controller.

• Ian's Ramp Time : 100 (ms)[AC]. I think this should get (ms)[AC], leave the setting read-only
• Julio's Ramp Time : 70 [AC] ms
  I we would know the FW version where this was changed, we could accommodate the regex.

I tested on the remote with

controller = asi.ASIMS2000("/dev/ttyUSB0", baudrate=115200, timeout=0.5)
s = controller.devices["stage"]
for n, v in s.get_all_settings().items():
    assert s.get_setting(n) == v
    if not s.describe_setting(n)["readonly"]:
        s.set_setting(n, v)

And there are still some issues with settings where the getters return something different than what the setters take. But all otherwise good.

Can you test this from my branch? https://github.com/juliomateoslangerak/microscope/tree/ASI_controller
I added some more stuff like moving both axes simultaneously. Also support for the LEDs in my controller but as you dont have those, I guess we have to find a way to make this a try-except thing.

[juliomateoslangerak]

I added an optional lights parameter to pass a list of lights that are connected so it should not break controllers without lights.

I push all of this to master.

[juliomateoslangerak]

This is also an option :o)
https://asiimaging.com/docs/flashing_ms2000_controller

[iandobbie]

Yes, but the system is actually running with an ancient version of slidebook and I don't want to brake the running TIRF setup, sorry.

[iandobbie]

I added an optional lights parameter to pass a list of lights that are connected so it should not break controllers without lights.

I don't think this parameter is optional. I think we need to test if lights exists as this generated an error until I added lights=[] to the setup call. With this if you call get_number_leds() it errors as the led_mapper doesn't exist. Just a bit of error checking needed I think, I will have a play and try and suggest a fix.

[juliomateoslangerak]

No. It’s not optional. In fact I get it through kwargs, which is probably not a good idea. Anyway, in the last commit i avoid this error you mention and you don’t have to provide an empty list of lights.

[iandobbie]

Rather than a try except why not switch on if learns.has_key(‘lights’)? We should also do the same for the stage parameter as we could easily have a controller that does light and/or other hardware but not a stage. Ian Sent from my iPhone On 3 Nov 2023, at 15:33, Julio Mateos Langerak ***@***.***> wrote:  No. It’s not optional. In fact I get it through kwargs, which is probably not a good idea. Anyway, in the last commit i avoid this error you mention and you don’t have to provide an empty list of lights. — Reply to this email directly, view it on GitHub<#289 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABJTBBKOVQMX4FU5PE6SON3YCVBJRAVCNFSM6AAAAAA6TJDBHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSHE4TEMBXGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[iandobbie]

This is also an option :o) https://asiimaging.com/docs/flashing_ms2000_controller

As I said I am reluctant, but can I just give a big shout out to a company which gives you explicit instructions on how you can update the firmware on their hardware. Big congrats to ASI!