qudi icon indicating copy to clipboard operation
qudi copied to clipboard

Setting Return slowness in confocal gui to one breaks scanning functionality

Open AndreaFilipovski opened this issue 6 years ago • 1 comments

What is affected by this bug?

Platform: windows 10 master branch: 4de82c07b47ae336eabf728b714606ac3eb9fe72 from the 08.01.2018 Modules: ni_card, confocal_logic, confocal_gui Main error happens in ni_card

When does this occur?

When the return slowness (points) is set to 1.

Where on the platform does it happen?

Scanner crashes Error Code: "Error while scanning line. Traceback (most recent call last): File "C:\Users\Lab01\Desktop\Software\qudi\hardware\ni_card.py", line 1366, in scan_line start=False) File "C:\Users\Lab01\Desktop\Software\qudi\hardware\ni_card.py", line 1198, in _write_scanner_ao None) File "", line 2, in function File "C:\Anaconda3\envs\qudi\lib\site-packages\PyDAQmx\DAQmxFunctions.py", line 29, in mafunction raise DAQError(error,errBuff.value.decode("utf-8"), f.name) PyDAQmx.DAQmxFunctions.DAQError: Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property. Property: DAQmx_SampQuant_SampPerChan Requested Value: 1 Maximum Value: 9223372036854775807 Minimum Value: 2

Task Name: ScannerAO

Status Code: -200077 in function DAQmxWriteAnalogF64" Error happens in _write_scanner_ao method, when used called by set_up_scanner() method.

How do we replicate the issue?

Setting return slowness value to 1

Expected behavior (i.e. solution)

?

Other Comments

This could be repaired by changing the input options in the gui and by chicking if return slowness value is whitin given range.

AndreaFilipovski avatar Feb 01 '18 16:02 AndreaFilipovski

Unfortunately, this might turn out to be quite a tricky one. Just 3 days ago I had a need to set return slowness to a value of 1 and it worked fine.

But... on that experiment I am not using an NI card at all. The scanning is being performed by NewFocus Piezo micrometer screws, and the counts are being collected through a Swabian Instruments TimeTagger. This means that I have an interfuse to tie these hardware modules together to satisfy the scanner interface.

I guess that my implementation of the scanline() method in this interfuse is capable of return_slowness =1 but for some reason the implementation in nicard hardware module is not.

This means that any fix at the logic or gui level is absolutely not right. One reasonable short-term solution would be to have the hardware file know about limits for things like return slowness (clock frequency is another one which should be bounded for certain hardware). There could be a get_slowness_range() method that he confocal logic can call to learn what is allowed. This is then suitably set individually per hardware module.

However, this kind of thing highlights something else that has become a problem recently. The current scanner interface is very tied to the NI card implementation for confocal scanning. It is not as general as an interface should be, and this is requiring a number of hacks. I will start a separate issue to discuss this problem.

latchr avatar Feb 01 '18 22:02 latchr