LabVIEW
DAQ output questions - multiple tasks per sample clock if only one is HW timed?
Solved!
You should be able to handle all of this with software timing. I think you've misunderstood how hardware and software timing works, so I'll summarize. (Please note this is valid for DAQmx; I have not used RIO devices).
Software timing means the output changes states when the host computer tells it to. If you have a loop that executes once a second and writes a value to the DAQ, that's software timing.
Hardware timing means the output changes when the DAQ device tells it to. If you give a buffer of points to your device and say "Hey, iterate through this buffer 1000 times a second", that's hardware timing. Your device will use an onboard clock to generate a very accurate 1000 Hz signal that causes an output change.
Both techniques can generate quasi-static outputs equally well. For DAQmx at least, the value of an output will stay the same after a write until you write to it again. You don't have to keep writing the value.
Software timing is often easiest to program, as you just call a function to say "Set the output to X" and it happens. Hardware timing is harder since you need to configure clocks, but it is FAR more accurate.
All of your code should probably be done software-timed. The watchdog timer could be configured to auto-run and toggle at 2 Hz, but if it's automatically doing it then it's not a very good watchdog. If your software fails, a hardware-timed output will keep going. If it's software timed, your watchdog will fail if your software fails.
Reacting to events in the program sounds software timed as well. If it's a single value, then definitely software timed. If it needs to, say, output a 10 Hz sine wave at 1000 samples/second, then you can start it from the software but have the sampling be hardware timed. That would still be considered hardware timed even if it starts from a software signal. It sounds like you're just changing the value, so software timed will be great for that as well.
Setting constant voltages is also a software timed thing. You need to set a value, then later set it to something else. The timing between signals is entirely dictated by the host computer, so that's by definition software timing.
All said, you don't even need to have multiple tasks. If you start a task, set a value, then stop the task, the value should stay the same (again- RIO may be different from DAQmx, test this.)
Last, a comment- "the values are either a single value or 0, I think this makes them digital"- you're close here. Digital lines are either 0V or 5V. Analog lines can be whatever you want. If you have a signal that, in practice, is either 0V or 7V, that will need to be analog since a digital line can only output a 0 or 1.
What RIO device do you have. What IO modules exactly?
I only know cRIO and C modules in practice and there not every module supports its own clock.
Some don't even have a clock. The FPGA program simply reads (or writes) an IO and that is it. If you want a specific timing you implement it with a timed loop or a normal loop with a timing method. And here the distinction between hardware timing and software timing gets a bit blurry. It's programmed in LabVIEW with loops so you could argue it is software timing, but that diagram is ultimately compiled into an FPGA bitfile that implements everything in hardware with real gates. So which of the two is it now??
For modules that have their own clock (or can use a clock from a module with a clock) things are again different. Here the module channels are truly hardware triggered and your "soft" hardware can't change that clock on the fly like that.
@Shiv0921 wrote:
Although we have an FPGA we're choosing not to use it on this project as our needs are met by the DAQ capabilities.
I'm interested in what you mean by this, it sounds like it could make quite a big difference. Is there something different to when programming regular DAQ that I should be aware of?
@rolfk wrote:For modules that have their own clock (or can use a clock from a module with a clock) things are again different. Here the module channels are truly hardware triggered and your "soft" hardware can't change that clock on the fly like that.
Well if you use the DAQmx API, things do get supposedly more interesting and I have no detailed experience with that.
None of your modules has an internal clock, so if this was programmed in FPGA, the timing would be determined by the FPGA loops.
How NI solves this in DAQmx without having to create some custom DAQmx FPGA backend on the fly I don't know. They obviously must have a way to configure something on the FPGA in some ways in order to implement a certain sampling rate.
@rolfk wrote:
How NI solves this in DAQmx without having to create some custom DAQmx FPGA backend on the fly I don't know. They obviously must have a way to configure something on the FPGA in some ways in order to implement a certain sampling rate.
I would assume the chassis itself has timing capabilities similar to cDAQ chassis. Those have timing chips built into them that can be shared with the output cards. Maybe they use the FPGA, but I bet it's a common chip that goes in all of their cDAQ/cRIO backbone stuff. Just a guess though.
