Labscript with a PXIe remote system

[Andrew Blackney]

Does anyone know if Labscript can interact with devices on a remotely controlled PXIe Chasis. I have a PXIe system connected via a PXIe 8301 and a thunderbolt cable to my laptop with Labscript installed. will labscript beable to interact with the cards on the PXIe chassis?

[Chris Billington]

Hi Andrew,

Labscript uses the Ni DAQmx driver to communicate with the devices, so as long as that driver works with the remote PXIe devices, it should be able to communicate with them.

You can find a list of hardware supported by the NI DAQmx driver here:

https://www.ni.com/pdf/manuals/374768ae.html

I am under the impression others are using remote PXI devices with labscript, so my strong inclination is to say that it should work!

Regards,

-Chris

On Tue, May 11, 2021 at 6:08 AM Andrew Blackney <andrewb...@gmail.com> wrote:

Does anyone know if Labscript can interact with devices on a remotely controlled PXIe Chasis. I have a PXIe system connected via a PXIe 8301 and a thunderbolt cable to my laptop with Labscript installed. will labscript beable to interact with the cards on the PXIe chassis?

--
You received this message because you are subscribed to the Google Groups "the labscript suite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuit...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/4d95d3da-ba11-46d2-be35-aa9dcc63b1d9n%40googlegroups.com.

[Lincoln Turner]

Hi Andrew,

Chris Vale's group at Swinburne University are using PXIe chassis running off ?isolated DC supplies with fibre connection to host controller card (I think) to run their new experiment using labscript. At least they were in 2019, I haven't caught up with them post-pandemic. As Chris B says, from the python driver perspective, it likely doesn't even know how the cards are connected... (and PXIe differs from PCIe only at a pretty low electrical level AFAIR).

Best,

Lincoln

To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/CAKy3cVvb4nTQVJ7VcDubu0J1CsqbJRbjs1XHnSiY9CZ8DTcaeQ%40mail.gmail.com.

--

Lincoln Turner

Senior Lecturer

Fellow - Monash Education Academy

School of Physics & Astronomy

Monash University

G.06, New Horizons Centre

20 Research Way, Clayton Campus

Victoria 3800, Australia

T: +61 3 9905 1726

bec.physics.monash.edu.au

[Andrew Blackney]

k so I have connected the  remote system and am trying to get the NI cards recognised and I am getting and error running the DAQmx get capabilites  and It recognises my PXIE-4499 but itf gets an error because it has no  AI at least that's what I can tell.

InvalidAttributeValueError: Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property. Property: DAQmx_AI_TermCfg Requested Value: DAQmx_Val_RSE Possible Values: DAQmx_Val_PseudoDiff Channel Name: PXI1Slot5/ai0 Task Name: _unnamedTask<4> Status Code: -200077 in function DAQmxCreateAIVoltageChan

[dihm....@gmail.com]

Andrew,

I believe this is due to an issue where NI DAQ cards that support simultaneous sampling on analog inputs do not quite conform to the standard DAQ design (meaning, they are missing properties that labscript assumes are present, see this issue). I actually recently made a PR that addresses that particular problem that may solve your issue that you could try.

If you test it out, do be sure to leave a comment on github. If everything works well, that is an important testing datapoint before merging into the mainline.

-David

[Andrew Blackney]

David,

thanks for the reply/ your PR appears to have gotten further down the rabitthole but I am greeted with a new error that seems like it could be a simple fix:

Traceback (most recent call last):

  File "get_capabilities.py", line 447, in <module>

    capabilities[model]["AI_start_delay"] = AI_start_delay(name)

  File "get_capabilities.py", line 191, in AI_start_delay

    chan, "", input_type, Vmin, Vmax, c.DAQmx_Val_Volts, None

UnboundLocalError: local variable 'input_type' referenced before assignment

[David Meyer]

Andrew,

Rabbit hole indeed!

It appears your 4499 device uses the pseudodiff analog input termination, which I had assumed we would never need so I didn't include any code to handle it. As you suspected, adding the necessary code is pretty easy, but now I am running into a deeper issue: how to define the analog input delay time.

Right now, labscript sends a digital trigger to the DAQs to signal acquisitions to start. This is done basically at the beginning of a buffered shot and the DAQ will sample the entire run. At the end of the run, the data is cut up as needed then saved. Delays between when the analog samples are triggered and when data starts actually being recorded lead to incorrect slicing of the end data. Your rather unique device uses a special delta-ADC that apparently suffers from very long filter delays that will desync the AIs from the start trigger. How it defines this delay is completely different than any other DAQ labscript currently supports, so I'm trying to work out a reasonable way to accommodate it without a bunch of other changes. The rub is that the delay is defined in terms of clock cycles, not absolute time, so if you change the AI sample rate, the delay change will scale accordingly. Your device does support functionality to automatically remove this delay, but using it would require pretty specific customization to the blacs acquisition worker to use it and it is specific to the 449x series of devices.

Anyway, I'm pushing enough changes to my PR such that you should be able to at least get running, but the sampling delays are NOT fixed. Could I enlist your help in testing things (since I don't actually have one of these myself)? Basically I just need you to set up a labscript shot where you T the triggering signal into an Analog Input and try to measure it. Given how labscript operates, that first trigger is actually before the shot has generally started, so you will probably need to connect some other device to the same clockline, tell it to do things, and try to measure when those triggers occur. If that doesn't make any sense, I can elaborate further.

-David

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/k-Uz10rNTLQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to labscriptsuit...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/363402ae-6542-4265-9a28-95e6e7e3b2e8n%40googlegroups.com.

[Andrew Blackney]

that does make sense and I actually just spent some time then working on the code to get it to where you just stated you are currently at I believe. I modified the get capabilities to add the pseudodiff case and made the code ignore pseudodiff cases in start_trig_delay:

the small additions made are starting at line 190:

    elif supp_types & c.DAQmx_Val_Bit_TermCfg_PseudoDIFF:

        input_type = c.DAQmx_Val_PseudoDiff

    task.CreateAIVoltageChan(

        chan, "", input_type, Vmin, Vmax, c.DAQmx_Val_Volts, None

    )

    task.CfgSampClkTiming(

        "", rate, c.DAQmx_Val_Rising, c.DAQmx_Val_ContSamps, num_samples

    )

    task.CfgDigEdgeStartTrig(clock_terminal, c.DAQmx_Val_Rising)

    start_trig_delay = float64()

    delay_from_sample_clock = float64()

    sample_timebase_rate = float64()

    if input_type != c.DAQmx_Val_PseudoDiff:

        task.GetStartTrigDelay(start_trig_delay)

[David Meyer]

Andrew,

That is almost exactly what I did. I've actually already went ahead and had a go at fixing the delay time calculations as well (uploaded in the last commit). I can't guarantee it will work right the first time since labscript does a fair bit of magic behind the scenes when passing device parameters around that I often struggle with. I do believe the logic is right though. If you could test things out (specifically whether the input timings are actually right), that would be much appreciated! Also, feel free to make comments on this code directly to the github PR.

Thanks,

-David

To view this discussion on the web, visit https://groups.google.com/d/msgid/labscriptsuite/779adef8-4fa4-4c20-9231-bae3d577e974n%40googlegroups.com.

[Andrew Blackney]

I will most certainly do that and report back any issues that arise.