python-microscope / microscope Goto Github PK

Requested at ELMI 2018.

Add support for PointGrey/FLIR cameras. Told that they are small, cheap, and decent enough.

Requested at ELMI 2018.

Hardware that performs automatic focus control. No code on our side, just have to control when that device should run so it does not happen in the middle of acquisition.

Cockpit calls set_power_mw(value) on laser devices to set laser power. This appears to work correctly for a dummy laser device and the DeepStar lasers, but does not always work correctly for Cobolt lasers.

Monitoring the Cobolt log shows that sometimes the laser power is set correctly, other times it is set to zero, or 0.0001W, often several times in quick succession.

In the LaserDevice base class:

    def set_power_mw(self, mw):
        """Set the power from an argument in mW and save the set point.

        Args:
            mw (float): Power in mW.  Value will be clipped to the
                valid range for the laser.  See the methods
                :func:`get_max_power_mw` and :func:`get_min_power_mw`
                to retrieve the valid range.

        Returns:
            void
        """
        mw = max(min(mw, self.get_max_power_mw()), self.get_min_power_mw())
        self._set_point = mw
        self._set_power_mw(mw)

In the Cobolt implementation:

    def _set_power_mw(self, mW):
        ## There is no minimum power in cobolt lasers.  Any
        ## non-negative number is accepted.
        W_str = '%.4f' % (mW / 1000.0)
        self._logger.info("Setting laser power to %s W.", W_str)
        return self.send(b'@cobasp ' + W_str.encode())

The correct power is not getting to CoboltLaser._set_power_mw. I suspect it's because the laser is reporting its max power incorrectly in the bounds check in LaserDevice.set_power_mw. We should perhaps query this once on device init, and store it on the device instance.

Requested at ELMI 2018.

Add support for microscope bodies which come with a stage, objective turret, fitlerwheel, etc.

Some deepstar lasers have the option to measure the actual laser power while others don't. In both cases the command P? exist, but if the device is not fit with it, the returned power value is non-sense. So our implementation only returns the set power (PP?). We could find whether the device is fit with the power monitoring option and only then fallback to return the set power.

We should be able to do this by interpreting the output of the STAT3. If the laser is equipped with the LDM.APC power monitoring option, then the value of AP (option #3 on STAT3 should be 1).

It is not clear what LaserDevice.set_power_mw is supposed to do if the new value is outside the range supported by the laser. The documentation says nothing.

The implementation for the sapphire and the cobolt lasers will set power to the minimum value allowed by the device if the value is below the limit, and leave the hardware to decide what to do in case the value is above. I'm unsure what the implementation for the deepstar laser does but it seems like it leaves both cases to the hardware.

Testing with real hardware, the sapphire laser ignores commands that set the power outside the valid range, and instead return an error message.

What do you reckon this method should do for values outside the range supported by the laser?

Clients (e.g. cockpit) can read back devices after submitting changes; need to ensure those changes have been completed before allowing readback to prevent spurious (old) values being sent back.

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

Should probably check exit_event and exit if appropriate in the 'while True ... try device init' loop.

Need to add support for Boulder SLM. There is a Dummy SLM but there is not an actual interface defined.

There is a micromanager python library providing acces to micromanager
https://micro-manager.org/wiki/Using_the_Micro-Manager_python_library

Would it be an idea to create a microscope wrapper to give some access to micromanager supported hardware?

J

Works again if camera is disabled then re-enabled.
Suspect fetch_thread isn't being started when use_callbacks is disabled.

microscope no longer works in Python 2, so we could remove some historical workarounds to make it work, and drop the dependency on six.

May thoughts on a stage Api are.

Number of axes
Name of axes

Then each axis needs

Hardware range
Soft limits
Home
Move relative
Move absolute
Speed (maybe accl and decl rate)
Get position
Time to move x

Can’t think of much else

We could have a generic serial device which then maps the calls to
specific strings as most of the stages are just serial devs with text
control strings.

Ian

Requested at ELMI 2018.

I'm told that Hamamatsu dCamAPI library supports all of their cameras.

I haven't got around to actual try it, but looking at the code, I'm pretty confident that it does not work, because the com port is passed as list of filters. Basically, the code is this:

class FilterWheelBase(Device):
    def __init__(self, filters, *args, **kwargs):
        super().__init__(*args, **kwargs)
        ## rest of code assumes filters to be a list of tuples

class ThorlabsFilterWheel(FilterWheelBase):
    def __init__(self, com, baud, timeout, **kwargs):
        ## com port is passed as first argument to the parent constructor
        ## which expects it to be a list of filters
        super().__init__(com, baud, timeout, **kwargs)

I have looked back in history and seems like it has always been this way. Are we actually using this anywhere?

setup.py is used for both installation, prepare distribution, and builds, including building documentation.

We import sphinx there to build the documentation which makes sphinx a requirement to run install.

This was reported by @juliomateoslangerak in microscope-cockpit/cockpit#314

I'm interrested in the pvcam part of your project. I've not found what is the version you use. I believe that there are few different pvcam libraries: Photometrics, Princeton Instruments.

I got a
AttributeError: function 'pl_cam_register_callback' not found
Looking in the Pvcam 2.7 user manual, I don't see that function.

Regards

Discovered this error in the course of testing something else. If you queue up a set of patterns with the queue_patterns() function and then queue up another set of patterns without clearing the first lot you get the following error:

Traceback (most recent call last):
    File "(stdin)", line 1 in (module)
    File "C:\Python\lib\site-package\Pyro4\core.py", line 186 in __call__ return self.__send(self.__name, args, kwargs)
    File "C:\Python\lib\site-package\Pyro4\core.py", line 470, in _pyroInvoke raise data
Exception: Time limit exceeded during the transfer.(error 258)

Additionally, queuing any subsequent patterns after this error results in the following error:

Traceback (most recent call last):
    File "(stdin)", line 1 in (module)
    File "C:\Python\lib\site-package\Pyro4\core.py", line 186 in __call__ return self.__send(self.__name, args, kwargs)
    File "C:\Python\lib\site-package\Pyro4\core.py", line 470, in _pyroInvoke raise data
Exception: Send failed
PCIS-DASK::ERR-201: The configuration API failed.(error 260)

David has a fix for this.

I took a look at the OBIS Operator's manual and the control for the Coherent OBIS is completely different of the control for the Coherent Sapphire :/

Behaviour for CameraDevice.set_exposure_time with values outside the valid range is undefined. The current behaviour is to clip it for AndorSDK3 while on PVCamera it is passed unchecked and left to libpvcam. The should have a defined behaviour for consistency.

This is similar to issue #51, which was defining behaviour for LaserDevice.set_power_mw for values outside the device valid range. I think the same logic and conclusion applies to camera exposure times. If so, we should clip the exposure time values. Anyone thinks otherwise?

With the Zyla, if I set the trigger_mode to 'External Exposure' I get this error when applying. Sorry for the frenchified windows error message (the specified module was not found). All the other trigger_modes do not throw errors.

Traceback (most recent call last):
  File "C:\Users\julio\PycharmProjects\cockpit\cockpit\gui\device.py", line 338, in <lambda>
    applyButton.Bind(wx.EVT_BUTTON, lambda evt: self.device.updateSettings(self.current))
  File "C:\Users\julio\PycharmProjects\cockpit\cockpit\interfaces\imager.py", line 79, in wrapper
    result = func(*args, **kwargs)
  File "C:\Users\julio\PycharmProjects\cockpit\cockpit\devices\microscopeCamera.py", line 113, in updateSettings
    self.proxy.update_settings(settings)
  File "C:\Users\julio\Applications\WinPython\python-3.6.5.amd64\lib\site-packages\pyro4-4.73-py3.6.egg\Pyro4\core.py", line 185, in __call__
    return self.__send(self.__name, args, kwargs)
  File "C:\Users\julio\Applications\WinPython\python-3.6.5.amd64\lib\site-packages\pyro4-4.73-py3.6.egg\Pyro4\core.py", line 467, in _pyroInvoke
    data = serializer.deserializeData(msg.data, compressed=msg.flags & message.FLAGS_COMPRESSED)
  File "C:\Users\julio\Applications\WinPython\python-3.6.5.amd64\lib\site-packages\pyro4-4.73-py3.6.egg\Pyro4\util.py", line 170, in deserializeData
    return self.loads(data)
  File "C:\Users\julio\Applications\WinPython\python-3.6.5.amd64\lib\site-packages\pyro4-4.73-py3.6.egg\Pyro4\util.py", line 451, in loads
    return pickle.loads(data)
  File "c:\users\julio\pycharmprojects\microscope\microscope\cameras\SDK3.py", line 37, in <module>
    _stdcall_libraries['ATCORE'] = ctypes.WinDLL('atcore')
  File "C:\Users\julio\Applications\WinPython\python-3.6.5.amd64\lib\ctypes\__init__.py", line 348, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 126] Le module spécifié est introuvable

Requested at ELMI 2018.

Add support for galvo scanners.

I took an old mac with a blank python tree (macos 10.12.5)
Installed homebrew
Installed python3 (brew install python3)
pip3 install microscope
Fails with
ModuleNotFoundError: No module named 'sphinx'

pip3 install sphinx, followed by pip3 install microscope works.

Requested at ELMI 2018

Users that have old commercial microscope that are no longer maintained, would be interested on using since it gets more difficult to use the old acquisition software. For example, a LSM 510.

Our Clients adds to itself the methods of the Pyro proxy but leaves the attributes behind. This is required to, for example, get the number of actuators from a deformable mirror. These are available in the proxy and can be seen with _pyroAttrs instead of _pyroMethods

Following on from microscope-cockpit/cockpit#369.

Julio finds that the Deepstar comms work only if he adds a 0.2s delay into write, but at a point where it should have no real effect. Without this delay, it looks like responses are either echos of the laser command (e.g. see the 'power response' lines in the loging output posted at MicronOxford/microscope#369), or junk.

I've asked him to test it without the delay, with a microscope version at or after 849316e.

If it works, great - the problem was resolved by 849316e.

If it doesn't work, my suspicion is that it's something to do with either the comms config that Julio is using (does his USB serial adapter do some local echo thing?), or with the DeepStar's three-state business (although I've no idea why it works fine at Oxford, in that case):

• state 0, S0, an error state - expects 16-byte commands incl. CR/LF
• state 1, S1, state after successful boot/reset - expects 16-byte commands incl. CR/LF
• state 2, S2, state after successful LASER ON - expects 7-byte commands incl. CR/LF

If Julio's test is not successful, then we need to keep track of laser state, and pad the command strings to the appropriate width ... although how do you decide what width string to send when you first fire up the software and don't know the laser state?

We need something where we store the specs we use to implement the interface to the devices we have. We already have a directory shared between us in micronadmin. However, that won't work if there's people outside micron working on microscope. Also, I'd prefer that people can't accidentally remove files.

Requested at ELMI 2018

Support for Arduino control over serial. Not sure what this would mean, I think we already do, we have a SerialDeviceMixin to mix with whatever type of device the arduino would be.

The deviceserver script sets its own handling of SIGTERM and SIGINT.
The handling involves setting a multiprocessing.Event() that signals
the child processes to exit, and then wait for the child to exit.

On Windows this doesn't seem to a be a problem. I think this is
because children don't inherit the handling from the parent or because
there's no process groups? I don't really know Windows.

Child processes inherit signal handling from the parent at time of
creation. In Linux with Python 2.7 and 3.4, after receiving SIGTERM,
both parent and child processes try to set the exit event. This on
the signal handling:

    print "%d handling signal" % (os.getpid())
    exit_event.set()
    print "%d set exit event" % (os.getpid())

shows that none of the processes returns from setting the exit event.
While this on the DeviceServer class:

        try:
            print ("%d waiting" %( os.getpid()))
            self.exit_event.wait()
            print ("%d done waiting" %( os.getpid()))
        except:
            print ("%d exception while waiting" %( os.getpid()))

shows that none of the child processes returns from waiting that the
event is set.

A possible fix would be to move the signal handling to after starting
the children processes. This has two issues: 1) signal handling not
setup by us if signal is received before spawning all the children; 2)
children spawned much later during a restart of a device would inherit
the signal handling that sets the exit event.

We could also set the signal handling on the DeviceServer class but
others using DeviceServer may be surprised to have it coming with its
own signal handling.

It would be useful to have test cameras with different behaviours. Currently, they only generate random images but in cockpit they can generate a wave and rotate the image each time. If this was an option when constructing the TesCamera, we could have:

• random : random values in all pixels
• black: all values zero
• white: max value for data type
• wave: like the dummy cameras in cockpit
• beam: bright beam somewhere on the image (which is what I wold like now to experiment with BeamDelta)

Requested at ELMI 2018.

Seems like National Instruments already has a python library that interfaces their own C library, also using ctypes.

The new Setting class and device settings systems handles enum types.
If a device setting is an enum, the settings system will have the
client return the enum value instead of the enum instance. However,
the setter for a setting does not do this.

Consider this device:

class Mode(enum.Enum):
    A = 1
    B = 2

class Thing(microscope.device.Device):
    def __init__(self):
        super().__init__()
        self._mode = Mode.A # type: Mode
        self.add_setting('mode', 'enum', self._get_mode, self._set_mode, Mode)

    def _get_mode(self) -> Mode:
        print("returning '%s' of class '%s'"
              % (self._mode, type(self._mode)))
        return self._mode

    def _set_mode(self, new_mode: Mode) -> None:
        print("setting to '%s' of class '%s'"
              % (new_mode, type(new_mode)))
        self._mode = new_mode

In this case, _get_mode() returns an instance of <enum 'Mode'> and
the paired _set_mode() takes an instance of <enum 'Mode'> too.

The settings system recognizes that the returned value is an enum and
returns the enum value instead.

>>> x = Thing()
>>> val = x.get_setting('mode')
>>> print("received '%s' of class '%s'" % (val, type(val)))
returning 'Mode.A' of class '<enum 'Mode'>'
received '1' of class '<class 'int'>'

However, when setting the value, no reverse conversion is done:

>>> x.set_setting('mode', 2)
setting to '2' of class '<class 'int'>'

So far, this has only been used in the new Andor camera class and all
the enums in there are IntEnum which are also ints where this
should not be an issue.

Most of our device constructors have *args, **kwargs and passe them to the parent. However, this is to open to errors that don't get caught. For example, this real case:

TestFilterWheel(filteres=[(0, 'DAPI', '430')]) # note typo on filters

which does not give an error, but has no filters defined.

And I don't think we actually need the flexibility that *args, **kwargs would give us because only the device specific type actually needs some argument. It also complicates things a bit when we have multiple inheritance. So I think we could just remove all that and everything should still work fine.

We currently wrap all device classes with Pyro.expose. We don't have any secret or unsafe methods in our devices, our private methods are only to signal that a method is not for public use. We could just configure the Pyro daemon to expose the methods by default.

This change would mean:

1. we no longer need to add Pyro code to all device modules and we no longer need to remember
2. users are free to pick whatever method they want for RPC

We have some Pyro4.behaviour('single') and Pyro4.oneway wrappers for the camera, not sure how to handle those.

My zyla Plus is not working.
I have a classic zyla 4.2 working and the plus version that does not work under microscope.
I have tested the last Andor Sdk without success. Will write details later.
I have also tested connecting the zyla + to the same workstation where the zyla classic is connected. The Sdk there should just be supporting zyla +.
Have you tested the plus version? If yes, which sdk version?

I am trying to validate microscope on the pi from my mac running cockpit. I have a single test camera, with lasest master branch. Cockpit from my mac connects but gets no pictures back. On the microscope console I get....

sudo deviceserver testconfig.py
2019-04-30 19:46:38,680:TestCamera:DEBUG:PID 5196: Debugging messages on.
2019-04-30 19:46:39,196:TestCamera:INFO:PID 5196: Initializing.
2019-04-30 19:46:39,726:TestCamera:INFO:PID 5196: Device initialized; starting daemon.
2019-04-30 19:46:39,734:TestCamera:INFO:PID 5196: Serving PYRO:[email protected]:8001
2019-04-30 19:46:49,220:TestCamera:DEBUG:PID 5196: Enabling ...
2019-04-30 19:46:49,232:TestCamera:INFO:PID 5196: Preparing for acquisition.
2019-04-30 19:46:49,233:TestCamera:INFO:PID 5196: Purging buffers.
2019-04-30 19:46:49,234:TestCamera:INFO:PID 5196: Creating buffers.
2019-04-30 19:46:49,234:TestCamera:INFO:PID 5196: Acquisition enabled.
2019-04-30 19:46:49,235:TestCamera:DEBUG:PID 5196: ... enabled.
2019-04-30 19:46:49,247:TestCamera:INFO:PID 5196: Current client is <Pyro4.core.Proxy at 0x751eca90; not connected; for PYRO:[email protected]:7702>.
2019-04-30 19:46:56,651:TestCamera:INFO:PID 5196: Trigger received; self._acquiring is True.
2019-04-30 19:46:56,652:TestCamera:INFO:PID 5196: Sending image
2019-04-30 19:46:56,773:TestCamera:INFO:PID 5196: Removing PYRO:[email protected]:7702 from client stack: disconnected.

Seems to me it is trying to send that data back to 127.0.0.1 which is the wrong place.

I suspect it's trying to send back an exception which involves some call or value from the DLL.

Replication: try to set the AOI_Binning parameter from cockpit settings panel with a camera on a remote machine. If microscope is not installed on the client machine, you'll see a 'no module mircroscope.SDK3' error; if it is installed but without the SDK3 DLL, you'll see a 'specified module could not be found' error.

We should make sure that, in the event of an exception, the remote sends back useful messages rather than references to objects in the microscope package.

Just tried the primeBSI with microscope and pvcam DLL version: 881. It fails with the output below. Not sure if this is a python3 issue or an updated dll issue but I definately got this to work when we first bought the cameras.

$ deviceserver ../test.py
2019-04-26 11:56:38,530:PVCamera:DEBUG:PID 7500: Debugging messages on.
2019-04-26 11:56:38,550:PVCamera:INFO:PID 7500: DLL version: 881
2019-04-26 11:56:38,550:PVCamera:INFO:PID 7500: Initializing b'PMUSBCam00'
2019-04-26 11:56:39,089:PVCamera:INFO:PID 7500: Failed to start device. Retrying in 5s.
Traceback (most recent call last):
File "C:\Python37\lib\site-packages\microscope-0.2.0+dev-py3.7.egg\microscope\cameras\pvcam.py", line 1419, in initialize
p.current
File "C:\Python37\lib\site-packages\microscope-0.2.0+dev-py3.7.egg\microscope\cameras\pvcam.py", line 1149, in current
return str(memoryview(self.raw).tobytes()) or ''
File "C:\Python37\lib\site-packages\microscope-0.2.0+dev-py3.7.egg\microscope\cameras\pvcam.py", line 1142, in raw
return self._query()
File "C:\Python37\lib\site-packages\microscope-0.2.0+dev-py3.7.egg\microscope\cameras\pvcam.py", line 1074, in _query
raise Exception('pvcam: parameter %s not supported in python.' % self.name)
Exception: pvcam: parameter PARAM_DD_INFO not supported in python.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "C:\Python37\lib\site-packages\microscope-0.2.0+dev-py3.7.egg\microscope\deviceserver.py", line 140, in run
self._device.initialize()
File "C:\Python37\lib\site-packages\microscope-0.2.0+dev-py3.7.egg\microscope\cameras\pvcam.py", line 1424, in initialize
if not err.message.startswith('pvcam error 49'):
AttributeError: 'Exception' object has no attribute 'message'

The methods get_binning and get_roi (as well as their setters) make use of lists of ints. However, we now have a Roi and Binning class which should be used across all the cameras.

Requested at ELMI 2018.

Fine control over the camera shutter.

We could add support for IDS uEye cameras. Vendor even supplies a Python package that wraps its own C library with ctypes.

Requested at ELMI 2018

Don't forget lightsheet microscopes.

Requested at ELMI 2018.

1. Make it easier for people who already have a µManager system to migrate to microscope
2. enable use of µManager drivers from microscope
3. enable use of microscope from µManager

pip install microscope

Write a config for deviceserver.

python -m microscope.deviceserver config

• works fine if microscope is in the cwd
• fails otherwise, as multiprocessing can't fork because it can't find deviceserver.

There appears to be a problem communicating with the Alpao mirror in hardware trigger mode. The first pattern sent using the function "apply_pattern" in mirror/alpao.py (lines 129-134) seems to be applied fine, but any subsequent patterns applied yield:

"Time limit exceeded during the transfer.(error 258)"

As an error message from self._raise_if_error(status) (line 134).

This only happens in hardware trigger mode. I'm unsure of how to rectify this as we need the Alpao in hardware trigger mode for experiments, but we also (currently) send it ad hoc, one off patterns from time to time. Potentially we could have a check in "apply_patterns" to see if the DM is in hardware trigger mode, if so, turn it back to software trigger mode, apply the sent single pattern and then swap back to the previous trigger mode, but that seems inelegant.

This also might be related to Issue #50, but that error occurred under Python 2 and we are now running Python 3.7. Additionally, whilst we have been running Python 3.7 for a number of weeks now, this problem only occurred in the last few days which makes me suspect something more is happening behind the scenes that I don't know enough to ascertain.

Finally, re-initialising a Pyro connection (as happens with Cockpit's startup) but not re-initialising the device serve on the remote and trying to send another pattern after getting the above error means one obtains a different error:

"Exception: Send failled.
PCIS-DASK::ERR-201: The configuration API failed.(error 260)"

However, I have a strong suspicion that whatever causes the error 258 is also causing this error 260 and so addressing the underlying issue should solve both.

The apply pattern in the alpao mirror only works in software trigger mode. However, it does not check for this and will happily send patterns which then never get applied.

The method should check the current trigger type, change it to software, send and apply the pattern, then revert to the previous state. If there are any patterns queued, this will empty the queue. This should also be documented on the abstract class.

The BMC mirror may suffer of the same issue.

What should the state of the laser after the constructor? Should it be left on whatever state it was before or should it be turned off? At the moment, the constructor makes no change but for the laser sapphire it would mean that it's left on (the laser is on as soon as the key switch is turned on). What about after initlize() ?

Also, should the constructor success if the key switch is off or interlock is open? Or should it fail during initialize?

The deviceserver process management works well on my Windows workstation, but fails to shutdown child processes on my Windows laptop.

Also, the use of the signals module means that the deviceserver can't be wrapped behind a windows service, which seems to be the only way to have scripts start automatically without logging in. Doing so raises the error "signals only works in the main thread", although querying the thread name at that point, it says it is the main thread.

We probably need to use separate event types under UNIX (signal) and Windows (win32event).

After some dll-hell I managed to reconnect the zyla using microscope.
Everything looks fine but there are no images

Server side config:
device(AndorSDK3, '10.6.19.30', 8001, timeout=1)

Server side STOUT:
2018-07-31 17:19:52,178:main:INFO:PID 4704: 4668 is alive.
2018-07-31 17:19:55,298:AndorSDK3:DEBUG:PID 4668: Debugging messages on.
2018-07-31 17:19:57,185:main:INFO:PID 4704: 4668 is alive.
2018-07-31 17:20:02,193:main:INFO:PID 4704: Aggregating reps. of: 4668 is alive.
Object <microscope.cameras.andorsdk3.AndorSDK3 object at 0x0000000005824B00>:
2018-07-31 17:20:14,985:AndorSDK3:INFO:PID 4668: Device initialized; starting daemon.
uri = PYRO:[email protected]:8001
Pyro daemon running.
2018-07-31 17:20:27,231:main:INFO:PID 4704: 5 times: 4668 is alive.

Cockpit side config:
[server]
ipAddress: 10.6.19.11
...
[Zyla-Cam1]
type: MicroscopeCamera
uri: PYRO:[email protected]:8001
dye: Reds
wavelength: 640
triggerSource: cRIO
triggerLine: 4
...

After enabling:
2018-07-31 17:24:13,744:AndorSDK3:DEBUG:PID 4668: Enabling ...
2018-07-31 17:24:13,744:AndorSDK3:DEBUG:PID 4668: Preparing for acquisition.
2018-07-31 17:24:13,744:AndorSDK3:DEBUG:PID 4668: Purging buffers.
2018-07-31 17:24:13,744:AndorSDK3:DEBUG:PID 4668: Creating 32 buffers.
2018-07-31 17:24:14,960:AndorSDK3:DEBUG:PID 4668: Acquisition enabled: True.
2018-07-31 17:24:14,960:AndorSDK3:DEBUG:PID 4668: ... enabled.
2018-07-31 17:24:14,960:AndorSDK3:INFO:PID 4668: Setting client to PYRO:[email protected]:7702.

After changing exposure time:
2018-07-31 17:26:58,059:AndorSDK3:DEBUG:PID 4668: Disabling acquisition.
2018-07-31 17:26:58,137:AndorSDK3:DEBUG:PID 4668: Set exposure time to 0.010000, resulting framerate 50.297763.
2018-07-31 17:26:58,137:AndorSDK3:DEBUG:PID 4668: Preparing for acquisition.
2018-07-31 17:26:58,308:AndorSDK3:DEBUG:PID 4668: Acquisition enabled: True.

I get all the options but no images. Experiment is running through my executor, trigger is triggering but no images.

How can I access the camera through the terminal window and try some software triggers?