DAQmx start task.vi - bottleneck

[NikGR]

Hello guys,

I recently switched form an old pci-mio-16e DAQmx card to a new system PXIe 1071 with 8301 controller and a 6363 DAQ card and I noticed that now my old "measurement.vi" runs much slower. I ran a performance and memory benchmark which showed a bottleneck with DAQmx start task.vi that runs at 50ms on average while my old card needed only 1ms.

Is this a common issue with the PXIe-6363 DAQ card or with the thunderbolt communication interface?

Is there any way to accelerate this DAQmx start task.vi on PXIe-6363?

Thank you!

[ZYOng]

The extra latency comes from the communication from the thunderbolt interface.

• When connecting PCI to the host PC directly:
  • Host PC <-> PCI-DAQ
• When using the thunderbolt interface:
  • Host PC <-> Thunderbolt Chip on Desktop <-> Thunderbolt cable <-> Thunderbolt Chip on PXIe-8301 <-> PXIe-6363

If you want to have a small latency similar to connecting the PCI module to the host PCI directly, you should remove the thunderbolt and use a PXIe controller directly.

[santo_13]

---

@NikGR wrote:

Hello guys,

I recently switched form an old pci-mio-16e DAQmx card to a new system PXIe 1071 with 8301 controller and a 6363 DAQ card and I noticed that now my old "measurement.vi" runs much slower. I ran a performance and memory benchmark which showed a bottleneck with DAQmx start task.vi that runs at 50ms on average while my old card needed only 1ms.

Is this a common issue with the PXIe-6363 DAQ card or with the thunderbolt communication interface?

Is there any way to accelerate this DAQmx start task.vi on PXIe-6363?

Thank you!

---

Just to confirm, your code is exactly the same between the 1ms benchmark and the 50ms one with a new system/card?

Typically DAQmx start task is more than just starting a task, dependent on the task type, configuration etc.,

[NikGR]

First of all thank you all of you guys for your immediate responses. 

My code is the same but previously I was running it through LabVIEW 2017 version and now through 2020.

The .vi has a multiple case structure and I managed to isolate the portion of the code that causes the bottleneck.

I found out that the bottleneck is only caused only on a DAQmx start task.vi and only for a Analog Input channel and it is about ~250ms.

Ιs it possible that we have reached some limit of the PXIe 6363 analog input multiplexer?

I post you guys my bottleneck.vi and a screenshot.

I've also tested this solution here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001DlKsCAK&l=en-GR but it didn't work, now the bottleneck is on DAQmx control task.vi

Sorry for the messy wiring which caused by changing LabVIEW version and copy/pastes, but the code is working. 

[Kevin_Price]

I made a couple small mods with comments and did some wire cleanup on the code.

Key points:

1. You don't need to create the task from scratch every iteration of the loop.  All the params are constants that can't change from iteration to iteration, so just do these things one time before entering the loop.

    Inside the loop, just Start, Read, and Stop the task.

2. Terminate the loop if there's a DAQ error (and show the error in an indicator).  You may need more logic here if you get frequent read timeout errors.  0.1 seconds is pretty short for a timeout unless the analog triggering conditions are always satisfied almost instantly.

3. Use the DAQmx task state model to "commit" the task before the first start.  You may still get your "bottleneck" here, but now it'll only happen once.

-Kevin P

[NikGR]

Thank you Kevin.

I will try to re-implement that in my code, however it is accepted as a partial solution because it wouldn't be the case if we didn't have so many Analog Inputs and we'd like to reuse some of them changing e.g. the sampling rate in every iteration.

It would be great to tell us if someone knows why this bottleneck happens only on Analog Input Channels of PXIe 6363.