Aurox issue on start-up

[NickHallPhysics]

The makeUI function asks for the settings to be described and asks for 'mode' but this doesn't seem to be a key in what I assume is a dictionary of settings.

Traceback (most recent call last): File "c:\cockpit\cockpit__init.py", line 142, in OnInit frame = mainWindow.makeWindow() File "c:\cockpit\cockpit\gui\mainWindow.py", line 386, in makeWindow window = MainWindow() File "c:\cockpit\cockpit\gui\mainWindow.py", line 203, in init item = thing.makeUI(topPanel) File "c:\cockpit\cockpit\devices\aurox.py", line 142, in makeUI mode_selector.Set(self.describe_setting('mode')['values']) File "C:\Program Files\Python37\lib\site-packages\pyro4-4.76-py3.7.egg\Pyro4\core.py", line 185, in call return self.send(self.__name, args, kwargs) File "C:\Program Files\Python37\lib\site-packages\pyro4-4.76-py3.7.egg\Pyro4\core.py", line 476, in _pyroInvoke raise data # if you see this in your traceback, you should probably inspect the remote traceback as well KeyError: 'mode'

[mickp]

Are you running the correct versions of both cockpit and microscope? You need the latest master for cockpit, and MicronOxford/microscope#124 for microscope.

[NickHallPhysics]

Apologies, I had not fulfilled all the necessary start-up requirements. All the necessary steps that you emailed over have been completed. Cockpit will now start. However, we're still having problems with starting up the Aurox.

If the config file is initialise with the Aurox device defined as;

device(aurox.Clarity, 'localhost' , 7001, {'camera': testdevices.TestCamera,})

As per the email but with address changed, then when you try to switch to the 'calibration' mode it switches back to raw and fails with the following traceback:

2019-12-10 15:18:20,719:Clarity (microscope.devices):ERROR:PID 20544: in set_setting(mode): Traceback (most recent call last): File "c:\microscope\microscope\devices.py", line 329, in set_setting self.settings[name].set(value) File "c:\microscope\microscope\devices.py", line 145, in set self._set(value) File "c:\microscope\microscope\filterwheels\aurox.py", line 176, in set_mode raise Exception ("Processing not available") Exception: Processing not available

Additionally, the camera then refuses to fire and only reads noise, presumably because cockpit is no longer being provided with an URI for the camera. To try and rectify this, I changes the Aurox config to:

device(aurox.Clarity, 'localhost' , 7001, {'camera': andorsdk3.AndorSDK3,})

However, this still produces the Aurox error and, additionally, results in an error when the camera is enabled which continuously occurs and can only be stopped by killing the device sever. Traceback provided below:

ctypes.ArgumentError: argument 1: <class 'TypeError'>: wrong type 2019-12-10 15:24:49,848:Clarity (microscope.devices):ERROR:PID 20544: in _fetch_loop: Traceback (most recent call last): File "c:\microscope\microscope\devices.py", line 554, in _fetch_loop data = self._fetch_data() File "c:\microscope\microscope\cameras\andorsdk3.py", line 376, in _fetch_data ptr, length = SDK3.WaitBuffer(self.handle, timeout) File "c:\microscope\microscope\cameras\SDK3.py", line 210, in call res = self.f(*ars)

[mickp]

Exception: Processing not available

Either opencv or Mark's processing module is not on the python path on the remote.

[mickp]

Not sure what's going on with the camera. The noise is probably when you had the Clarity configured to set up a TestCamera instance. That type error in SDK3 is weird. I'm not sure, but it looks like something is being passed to (or back from) a DLL function with the wrong type. Is this a USB or CameraLink Zyla? Possibilities to look at:

• self.handle is not a ctype
• timeout is None
• The camera is trying to blit m-bit data into an n-bit buffer where m≠n .

[mickp]

This is almost certainly a microscope issue, so transferred issue there.

[mickp]

Nick says the camera was working when served directly from DeviceServer, but it isn't working when served from a ControllerDevice. I suspect:

• there's a difference in the way that DeviceServer and ControllerDevice initialise devices;
• the device handle is still None in the ControllerDevice case.

[mickp]

Looks like Clarity never calls super().initialize(), so the camera never gets connected.

[mickp]

Should be fixed, now.

I also added some checks on TestCamera so it will throw exceptions if it should be initialized to perform an action but isn't. I did this using a decorator function in testsuite.devices, but perhaps this would be useful in the main devices module to avoid esoteric error messages.

I've also switched around the order that DataDevice enables hardware and starts the collection thread. Before, we started the collection thread, then enabled the hardware. Now, I enable the hardware, then start the collection thread. This seems to make more sense:

• starting a thread is pretty quick, so enabling is probably the slower step;
• we probably shouldn't start the collection thread if the device fails to enable;
• starting the thread after enable prevents potential calls to the hardware in _fetch_data that may rely on it being enabled.

[mickp]

David - can you take a look at these changes in #124 ?

[NickHallPhysics]

I think the changes in commit 84e042f breaks the Andor Zyla as the device server fails with the following traceback:

2019-12-11 13:03:46,347:AndorSDK3 (microscope.deviceserver):INFO:PID 3812: Failed to start device. Retrying in 5s. Traceback (most recent call last): File "c:\microscope\microscope\cameras\andorsdk3.py", line 412, in initialize self.handle = SDK3.Open(self._index) File "c:\microscope\microscope\cameras\SDK3.py", line 218, in call raise CameraError(self.name, res) microscope.cameras.SDK3.CameraError: when calling AT_Open - AT_ERR_OUTOFRANGE

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "c:\microscope\microscope\deviceserver.py", line 182, in run self._device.initialize() File "c:\microscope\microscope\cameras\andorsdk3.py", line 414, in initialize raise Exception("Problem opening camera.") Exception: Problem opening camera.

This happens both when the camera associated with the clarity is the Andor or a TestCamera. In the former case, the problem opening the camera also causes the clarity process to fail with the following traceback:

2019-12-11 13:11:57,798:Clarity (microscope.deviceserver):INFO:PID 1260: Failed to start device. Retrying in 5s. Traceback (most recent call last): File "c:\microscope\microscope\cameras\andorsdk3.py", line 412, in initialize self.handle = SDK3.Open(self._index) File "c:\microscope\microscope\cameras\SDK3.py", line 218, in call raise CameraError(self.name, res) microscope.cameras.SDK3.CameraError: when calling AT_Open - AT_ERR_OUTOFRANGE

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "c:\microscope\microscope\deviceserver.py", line 182, in run self._device.initialize() File "c:\microscope\microscope\filterwheels\aurox.py", line 357, in initialize super().initialize() File "c:\microscope\microscope\devices.py", line 1164, in initialize d.initialize() File "c:\microscope\microscope\cameras\andorsdk3.py", line 414, in initialize raise Exception("Problem opening camera.") Exception: Problem opening camera.

[mickp]

I don't think it's related to 84e042f: the error is happening during the library call to open the camera. AT_ERR_OUTOFRANGE suggests self._index is larger than the number of available cameras.

[mickp]

Resolved. The final problem was that the config file contained a device entry for the camera in addition (and prior) to specifying it as the Clarity's camera. What happens is that first process binds to the camera, so it's not available to the Clarity when it tries to connect and an AT_ERR_OUTOFRANGE exception is thrown.