Digital Output Ni 6363

[emanuel...@me.com]

Hi there,

I am a physics master student trying to get a NI_6353 running with the Labscript Suite for my project/experiment. The setup of the suite seems to have worked. In Manual Model Digital and Analog Outputs work well. So from Blacs the Digital Outs can be set to high or low without getting an error. When using a test program with just an analog output it works from Runmanager as well.

If I try to add a Digital Output the program runs as it should (traced on an oscilloscope) in the first place but then enters an error state in Blacs. 

I get the same error even if I do not use the Digital Out in the program - it is enough to write the channel in the experiment connection table. If the Digital Out is not in experiment connection table - a program using analog outputs runs perfectly well.

It would be really cool if someone could help me with this issue - if tried for quite some time to solve it by myself but couldn't come to an end...

Thanks in advance!

Regards,

Emanuel

Exception in worker - Fri Mar 18, 11:30:47 :
Traceback (most recent call last):
  File "C:\labscript_suite\labscript_devices\NI_PCIe_6363.py", line 262, in transition_to_manual
    self.do_task.StopTask()
  File "<string>", line 3, in StopTask
  File "<string>", line 2, in function
  File "C:\Python27\lib\site-packages\PyDAQmx\DAQmxFunctions.py", line 34, in mafunction
    raise DAQError(error,errBuff.value.decode("utf-8"), f.__name__)
DAQError: Finite acquisition or generation has been stopped before the requested number of samples were acquired or generated.
 in function DAQmxStopTask

Fatal exception in main process - Fri Mar 18, 11:30:47 :
Traceback (most recent call last):
  File "C:\labscript_suite\blacs\tab_base_classes.py", line 670, in mainloop
    next_yield = inmain(generator.send,results)
  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 74, in inmain
    return get_inmain_result(in_main_later(fn,False,*args,**kwargs))
  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 94, in get_inmain_result
    exec('raise type, value, traceback')
  File "C:\Python27\lib\site-packages\qtutils\invoke_in_main.py", line 53, in event
    result = event.fn(*event.args, **event.kwargs)
  File "C:\labscript_suite\blacs\device_base_class.py", line 627, in transition_to_manual
    raise Exception('Could not transition to manual. You must restart this device to continue')
Exception: Could not transition to manual. You must restart this device to continue

Lab Connection Table:

from labscript import *

from labscript_devices.PineBlaster import PineBlaster

from labscript_devices.NI_PCIe_6363 import NI_PCIe_6363

PineBlaster('pseudoclock_0')

NI_PCIe_6363('ni_card_0', parent_device=pseudoclock_0.clockline, MAX_name='Dev1', clock_terminal='/Dev1/PFI1', acquisition_rate=300000)

DigitalOut(name='d_out0', parent_device=ni_card_0, connection='port0/line0')

DigitalOut(name='d_out1', parent_device=ni_card_0, connection='port0/line1')

AnalogOut(name='a_out0', parent_device=ni_card_0, connection='ao0')

AnalogOut(name='a_out1', parent_device=ni_card_0, connection='ao1')

AnalogIn(name='a_in0', parent_device=ni_card_0, connection='ai0')

AnalogIn(name='a_in1', parent_device=ni_card_0, connection='ai1')

AnalogIn(name='a_in2', parent_device=ni_card_0, connection='ai2')

start()

stop(1)

Test Program:

import __init__ # only have to do this because we're inside the labscript directory

from labscript import *

from labscript_devices.NI_PCIe_6363 import NI_PCIe_6363

from labscript_devices.PineBlaster import PineBlaster

from labscript_utils.unitconversions import *

PineBlaster(name='pseudoclock_0')

NI_PCIe_6363('ni_card_0', parent_device=pseudoclock_0.clockline, MAX_name='Dev1', clock_terminal='/Dev1/PFI1')

# Create the output/input channels on the above devices

DigitalOut(name='d_out0', parent_device=ni_card_0, connection='port0/line0')

AnalogOut(name='a_out0', parent_device=ni_card_0, connection='ao0')

rate = 1e4

start()

t = 0

a_out0.constant(t, 0.3)

t += 2  

a_out0.constant(t, 0)

t += 1

d_out0.go_high(t)

t += 1

d_out0.go_low(t)

t += 1

stop(t)

[Philip Starkey]

Hi Emanuel,

Thanks for getting in contact with us. The 6353 looks very similar to the 6363 we use, so I would have expected it to work. However, there are a few possibilities that might explain the error:

1. There could be an issue specific to the version of DAQmx you have installed. Could you provide the version of NI DAQmx (and also PyDAQmx) you have installed?
   Our lab PCs are quite out of date, and are running DAQmx v9.2.3, so perhaps there might be something that we need to support differently if you are running a newer version.
   
   
2. It could be something to do with your particular hardware setup. Does the NI card use a USB, PCIe or PXI interface? Does the connection run through anything else? (for instance our PCI/PCIe devices are connected to the PC via an Adnaco PCI/PCIe range extender over optical fibre. At least one person has reported issues with such a device on the NI forum, although we've never seen any with ours when using DAQmx v9.2.3)
   
   
3. There may be an issue with only using a single Analog and Digital Output. Some NI devices need an even number of Analog and Digital Outputs configured to work correctly. While you have these specified in your connection table, you only have one of each in your test script. Could you check to see if the same error occurs if you have two analog and two digital channels in your test script?
   
   
4. There might be an NI 6353 specific issue with sharing the input clock (from the PineBlaster) between the analog and digital generation sections of the NI card. Could you see what happens if you only have Digital outputs? (remove the AnalogOuts entirely)

If you could also send through one of the h5 files you have tried to run, along with an oscilloscope trace showing the output (including a trace of the clock output from the PineBlaster which you are feeding to PFI1) that would be great (just so we can confirm that the number of clock ticks from the PineBlaster matches the number of instructions being programmed into the NI card)

Hopefully one of these leads us in the right direction to solve your issue!

Cheers,

Phil Starkey

[Emanuel Berger]

Hi Phil,

Thanks for your quick reply!

The version of NI DAQmx is 14.0, the version of pyDAQmx is 1.3.2. Both of them are quite new versions. Should I try to change the version? We are using Windows 8. I do not know whether the old versions are compatible… 

I can hardly imagine that the basic commands have changed - especially since in manual mode everything seems to work, also the digital outputs. I can change the settings by hand and trace them on the oscilloscope... 

There seems to be a problem when closing the buffered mode - there still seems to be some writing process running - even if I just initialize one DigitalOut (and no other channels) and let the program run for 1 second without doing anything - no go_high() and so on. In general the program I set up run as expected (also the digital outs)- but if I use DigitalOut after the correct run it goes in an error. 

I am using a PCIe 6353 device. It is located directly in the computer and clipped onto the board. 

Regarding a single output and multiple ones. I used two analog out and everything went well. 

Regarding the digital ones I tried 1, 2, 8 and 32 outputs at the same time. It did not work unfortunately. (I just initialized them and made no commands - so I expected them to stay at 0 during the run except one output which was set to high and then to low again.)

It is allways the same error.

Could there be something regarding the PFI outputs?

Could it be possible that I am missing some special Python module? (One that would be needed only during buffered mode?) 

I attached you 3 different files and two oscilloscope pictures. It would be awesome if you could check them! 

„8_do_then_error“ uses 8 digital outputs (I changed the lab connection table accordingly)

„2_ao_1_ai“ is without digital outs and runs perfectly well.

„1_do_then_error“ uses one digital out

the clockoutput can be seen on D1 on the oscilloscope.

Thank you so much for your help! Best regards to Australia,

Emanuel

[Philip Starkey]

Hi Emanuel,

I've tried to reproduce this with a NI PCIe 6363 using DAQmx 14.2, but couldn't. I'll try again tomorrow with DAQmx 14.0 (the NI server was slow and it took about 2 hours to download and I then ran out of time). I think we did see an error once on a newer version of DAQmx, but unfortunately didn't debug it at the time and went back to the previous configuration. So it's unclear whether it was the DAQmx version or something else that was the issue.

I believe I have identified an error in labscript, which causes the final clock tick to be much shorter than it should be. I think it is unlikely that this is the cause of the error though, but it could be worth trying to fix anyway. Line 733 in labscript.py currently reads clock.append({'start': time, 'reps': 1, 'step': 10.0/self.clock_limit, 'enabled_clocks':enabled_clocks}). It should instead be clock.append({'start': time, 'reps': 1, 'step': 10.0/local_clock_limit, 'enabled_clocks':enabled_clocks}). Let me know if this change makes any difference!

Is it possible for you to try upgrading to DAQmx 14.2 to see if the error persists? You could also try updating to the latest version, 15.5 as well (which I'll also try to test tomorrow). This will at least rule out the DAQmx version if it doesn't fix the problem.

I'll also try and make a minimalistic example program tomorrow that will allow you to adjust the number of instructions and clock ticks sent to the NI card to see if you can deduce exactly which instruction it thinks it didn't get a clock tick for.

Cheers,

Phil

P.S. Out of curiosity, which institution/group are you working in?

[Emanuel Berger]

Hi Phil,

Thanks for your help! That is really amazing!

I corrected this line in labscript.py but it made no difference. 

I just tried another thing: I replaced in the device file NI_PCIe_6363.py in line 216 „DAQmx_Val_FiniteSamps" with „DAQmx_Val_ContSamps". That resolves the error (at least for the moment). So the program seems to really ‚feel‘ some missmatch with the clock.

Do you think that this will lead to an error somewhere else in the suite? I just tried some simple programs using digital (trigger) signals and digital output - they worked just fine...

Does it still make sense in this case to do the upgrade to 14.2 or newer?

Regards,

Emanuel

PS: I am working for the Photonics group in Zurich.

--
You received this message because you are subscribed to a topic in the Google Groups "The labscript suite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/labscriptsuite/WXu4XTs7t20/unsubscribe.
To unsubscribe from this group and all its topics, send an email to labscriptsuit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philip Starkey]

Hi Emanuel,

Very interesting. I'll have to investigate DAQmx_Val_ContSamps. It's not clear from the documentation whether this just allows you to choose to add more to the output buffer later if you want, or if it will actually wrap around and repeat the output if you have too many clock ticks. If it is the latter, it would be better to solve the issue another way in case we accidentally start outputting the start of the shot again at the end due to an incorrect number of clock ticks.

I've also noticed that the analog output code seems to strip the last time point from the array. Based on the comment, it appears this was copied over from the NI PCI 6733 code, and may or may not be applicable to the NI PCIe 6353/6363. And it is not clear whether this should be done to the digital output array too. You're welcome to experiment while I sleep, otherwise I'll let you know what I find tomorrow!

Cheers,

Phil

To unsubscribe from this group and all its topics, send an email to labscriptsuite+unsubscribe@googlegroups.com.

[Philip Starkey]

Hi Emanuel,

I've managed to install NI DAQmx v14.0 today and I was able to reproduce the bug. Nothing I did seemed to make it go away, except for that change you described in your previous email (and I'm still not entirely sure what that change is doing!).

The good news is that the issue does not exist on NI DAQmx v14.2 or v15.5. So it seems reasonable to conclude NI made a mistake with that release. I'm pushing a new version of the NI_PCIe_6363 labscript_devices class to the bitbucket repository today which will raise an exception if you are using a DAQmx version of 14.0 or 14.1 (in case 14.1 has the same problem). I would strongly recommend you roll your copy of labscript_devices/NI_PCIe_6363.py back to the version that uses the DAQmx_Val_FiniteSamps option and upgrade your version of DAQmx so as to maintain compatibility with future labscript releases.

Hopefully the upgrade will solve your problem!

Cheers,

Phil