LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx hardware timing AO/DO errors

Solved!
Go to solution

Hello, I have a subVI (attached) that takes care of all of my analog and digital I/O on my cRIO. AI/DI signals come into the code, get processed in other areas of my program to create output signals, and AO/DO signals are written to the device. I am running into issues with the attached code that seem to be from buffers/timing. Hardware timing is something that has been tricky for me this whole time, so any advice would be wonderful.

 

I found a NI article that discussed timing multiple different channels and it suggested placing the the DAQmx Start Task VIs in a sequence structure that follows the sequence you want them to execute. My first question is, does the way I've done it here look right?

 

Now regarding the errors, in the list below the two probes with no errors are from my AI and DI tasks. The other three are AO and DO, so clearly I'm doing something wrong with my outputs (my main VI front panel shows the appropriate readings for temp and voltage inputs, which further suggests that I'm only messing up outputs right now).

 

rseabeck_0-1632149040090.png

 

The error on probe 78 (code -89137) seems like it may be due to the fact that the module in that slot is DI/DO. Maybe I'm running into an issue where it's trying to read and write at the same time or something? Not quite sure. The other two errors (code -200462) suggest something to do with an empty buffer, so that goes back to the DAQmx Timing VI. Is this one because there's no data yet to be written to the device? Can I bypass this error code and let the program catch up until there is data to be written?

 

I could just switch to software timing (I only want to read/write every quarter second or so, and it's not critical that that occurs dead on every quarter second) and probably make my life a little easier, but I'd like to figure out this hardware timing so that I know what to do in the future if I ever have to read/write at a faster rate.

 

Also, my apologies if I haven't made things clear. Let me know if I need to clarify something in my code and I'll be happy to do so.

0 Kudos
Message 1 of 3
(1,003 Views)
Solution
Accepted by rseabeck

You'll get more eyes on this if you choose "File->Save for Previous Version..." and choose something like LV 2016 or so.  I (and many other long-timers) tend not to be early adopters of every new LV version as it comes out.  In my case (and probably many others'), version upgrades can mean a lot of pretty big config management and hardware support issues to deal with so we wait for a compelling reason.

 

The empty buffer error might be due to starting the task before writing data to it.  With a buffered, hw-clocked task, you must write your data *before* starting the task.  This is a pretty easy error to stumble into because software-timed unbuffered tasks use the *opposite* sequence (write *after* start).

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 3
(971 Views)

Bit late on the reply here, but thank you for your insight. I ended up switching to software timing. I began to realize how little I understand about hardware timing in DAQmx, and for my purposes software timing is plenty acceptable.

 

I just started the Data Acquisition with DAQmx course, so hopefully when I have to write a program with hardware timing I won't have to come here for help 🙂

 

Thanks again!

0 Kudos
Message 3 of 3
(943 Views)