Confocal scanner interface is too tied to NI card implementation - needs generalising

[latchr]

What is affected by this bug?

Any confocal scanner implementation that does not use the "canonical" NIcard implementation is affected, and requires some level of hacking to get working. There are many other ways to achieve confocal imaging - in the QMAPP group at Macquarie there are now 4 different confocal setups that do the scanning without NIcards.

For example, an interfuse has been developed to use any motor hardware (satisfying the motor interface) with the counter logic to do simple (but slow) confocal scans. See file logic/interfuse/confocal_scanner_motor_interfuse.py at https://github.com/QMAPP-mq/qudi/tree/dev_scanner_motor_interfuse - this module is still under active development and rather dirty but already functional.

When does this occur?

The problem is immediately apparent when trying to make interfuse modules to satisfy the confocal_scanner_interface using various non-NI hardware solutions.

Where on the platform does it happen?

Communication from the confocal logic to the hardware.

How do we replicate the issue?

Open interface/confocal_scanner_interface.py and look at the defined methods. Some are clearly NI-card specific or not fully general, eg:

• set_voltage_range (because the confocal scanner logic should only need to know about distances)
• set_up_scanner_clock
• set_up_scanner
• close_scanner_clock

Expected behavior (i.e. solution)

The interface should be generally applicable to a range of plausible hardware solutions for confocal scanning.

Other Comments

Pull request #258 touched on this issue by mentioning the need to "rethink the NIcard" stuff. Also, issue #311 highlights the fact that some bugs only apply to the NIcard implementation but do not impact other hardware.

[AndreaFilipovski]

I had the same problem implementing the confocal step scanner (using steppers instead of piezos), in this case attocubes.

I wrote a completely new logic instead of using an interfuse because Interfuse kind of seemed like patching up things.

Furthermore I need to be able to control the hardware without the step scan as well.

I think this all goes into the same direction.

NIDAQ and Confocal are not programmed according to the hardware-logic separation. This wasn’t a problem when using it as nearly everyone does it here but seems to become more and more of a problem now.

I suggest we wait with the fix if you agree until I merged the new things into NIDAQ as we afterwards wanted to see how we can change NIDAQ more sensibly, which is a big project.

During this process the Confocal logic will have to be changed as well, which will, to some extent take care of this interface and logic problem.

I think, when this is started it would be very helpful to have input from people with different hardware.

Maybe some code of the stepper could also be “reused”, if you feel like it maybe some people could have a look at it. Let me just warn you, basic functionality is given, however some things like continue stepping are note implemented correctly yet, which is one of the reasons I did not want to merge it fully into the master yet.

•      Andrea
  

Von: Lachlan Rogers [mailto:[email protected]] Gesendet: Freitag, 2. Februar 2018 00:01 An: Ulm-IQO/qudi [email protected] Cc: Subscribed [email protected] Betreff: [Ulm-IQO/qudi] Confocal scanner interface is too tied to NI card implementation - needs generalising (#312)

What is affected by this bug?

Any confocal scanner implementation that does not use the "canonical" NIcard implementation is affected, and requires some level of hacking to get working. There are many other ways to achieve confocal imaging - in the QMAPP group at Macquarie there are now 4 different confocal setups that do the scanning without NIcards.

For example, an interfuse has been developed to use any motor hardware (satisfying the motor interface) with the counter logic to do simple (but slow) confocal scans. See file logic/interfuse/confocal_scanner_motor_interfuse.py at https://github.com/QMAPP-mq/qudi/tree/dev_scanner_motor_interfuse - this module is still under active development and rather dirty but already functional.

When does this occur?

The problem is immediately apparent when trying to make interfuse modules to satisfy the confocal_scanner_interface using various non-NI hardware solutions.

Where on the platform does it happen?

Communication from the confocal logic to the hardware.

How do we replicate the issue?

Open interface/confocal_scanner_interface.py and look at the defined methods. Some are clearly NI-card specific or not fully general, eg:

• set_voltage_range (because the confocal scanner logic should only need to know about distances)
• set_up_scanner_clock
• set_up_scanner
• close_scanner_clock

Expected behavior (i.e. solution)

The interface should be generally applicable to a range of plausible hardware solutions for confocal scanning.

Other Comments

Pull request #258 https://github.com/Ulm-IQO/qudi/pull/258 touched on this issue by mentioning the need to "rethink the NIcard" stuff. Also, issue #311 https://github.com/Ulm-IQO/qudi/issues/311 highlights the fact that some bugs only apply to the NIcard implementation but do not impact other hardware.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ulm-IQO/qudi/issues/312 , or mute the thread https://github.com/notifications/unsubscribe-auth/AWacL_CRYg3ZmiaBHtMDCFhtwg3-Sy21ks5tQkIpgaJpZM4R2bEs . https://github.com/notifications/beacon/AWacL9B4GtExTDO4jCoR6lWG5duCzZkWks5tQkIpgaJpZM4R2bEs.gif