Slow DI response

[JimMarihew]

I am using a cDAQ to control my test stand.  My main loop reads the analog and digital inputs.  The loop timing is ~10ms.  The pressure transducers are not connected so they are noisy, and because of that I can see that the indicators are being updated very rapidly.  The problem I am having is when I activate one of the digital inputs there is a 5-10 second delay before the indicator updates.  I can see that the LED on the cDAQ responds instantly.  What could be causing this delay?

[GerdW]

Hi Jim,

---

@JimMarihew wrote:

The problem I am having is when I activate one of the digital inputs there is a 5-10 second delay before the indicator updates.  I can see that the LED on the cDAQ responds instantly.  What could be causing this delay?

---

One reason could be the way you initialized your DAQmx task.

How did you define them using which parameters?

Do you really need to use semaphores?

Did you try to execute all those DAQmx tasks in parallel instead of chaining them using one DAQmxRead after the other?

[Eric1977]

Along with what GerdW stated, I'd also add to please upload your VI. We'll be able to assist you far better that way than by images you submit to us.

[JimMarihew]

Hi Gerd,

The tasks are defined in MAX.  The DI is defined as a digital port input.  To maximize the speed of the input loop I put the controls in a separate loop in an event structure.  The semaphore is to prevent the two loops from trying to talk to the DAQ at the same time.  Not sure if DAQmx would act as the traffic cop in such an event.  I did not try to do the tasks in parallel for the same reason.  

As I was typing my response I realized that if the DI task was having an error, I don't have an error handler to catch it.  I do now and attached is the error.

[JimMarihew]

Sure, here it is.

[JimMarihew]

The response time issue appears to have been the task.  I renamed the task and created a new one, and the indicator changes appropriately when I activate the sensor.  I added an iteration counter and I am still getting the error -200279 after 100-200 iterations.  I added an indicator on the error wire before the DI and there was no incoming errors. 

[GerdW]

Hi Jim,

wow, those VIs are quite old, aren't they?

You still don't show how all those DAQmx tasks are defined!

Which parameters are used to create them? How should we help with DAQmx problems when you keep relevant information hidden?

The error messages indicates you created a hardware-timed DI task: this does NOT fit with DAQmxRead set to read "1 channel 1 sample"!

As said before: I would use one loop per task…

What's the point of that lower loop to save the data to file? In the producer loop you already use a case structure to decide on "save data"/"do not save data" - in the consumer loop you need to check this condition again? Either there is data in the queue to save - or there is no data to save…

Why do you need those semaphores? In the event structure you use an AO and DO task, in the producer loop you use AI, TC, DI, FLOW tasks. How should they interfere?

[JimMarihew]

Hi Gerd,

Here are the Tasks.  I don't understand your comment on timing.  The configuration says that the timing for the DI task is "on demand".

In the past I had a program that was crashing, and the errors I was getting led me to believe that I might be having 2 VIs trying to talk to the cDAQ at the same time and the device locked up.  I added a semaphore to prevent this and the program stopped crashing.  I was using DAQmx talking directly to the devices, not tasks.  Was it just a coincidence that the errors stopped when I added the semaphores?  Perhaps I changed something else at the same time and didn't realize it.  Would using tasks have made a diffrence?

Very good point regarding the queue.

[GerdW]

Hi Jim,

the TC task is set to a sample rate of 100 S/s, but here again you just read "1 sample" per DAQmxRead call. This will quickly lead to "buffer overrun" errors…

[JimMarihew]

But it's set to read 10 samples in the TC task.  The DI was just added yesterday.  Before that it ran for hours with no errors.  Right now I am running it with the DI task disabled and it is over 40k iterations without the error.