LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQ output questions - multiple tasks per sample clock if only one is HW timed?

Solved!
Go to solution

I realise this is so simple but I'm stuck somewhere between software vs hardware timing and how many tasks a module can handle. (plus how to keep an output as high without having to write continuously to it? it's okay if this isn't possible, i just thought it was expected behavior, yet I can't create it)

Been looking at the examples but it hasn't cleared things up.

 

Scenario:
I have a RIO which has a timing clock per module (AI, AO, DIO)
I have a set of outputs whose values are either a single value or 0, I think this makes them digital.

One output is for an external watchdog, so needs to pulse every 0.5s (so hardware timed?)
Four are reacting to events in the program (so software timed?)
Two are for power supplies, they need to be set to a voltage at the beginning of the program, stay at this, and then go to 0V at the end. (hardware timed?)

The rates of these are different, and will be used in different parts of the program, so it would be handy to have multiple tasks.

 

So firstly, can I have multiple tasks on the same module if only one uses the sample clock? So 1 hardware-timed task and then another four software timed tasks?
Secondly, is it possible to somehow set the power supply value and then not have to touch it again until I need to zero it? I'm wondering whether this is what happens with the hardware timed ones, where you set it and it gives the illusion of staying high without being continuously written to, when actually it is being written to by the DAQ. Then the software timed ones are where you actually need to repeat 'write', is that correct?
Finally, if I do need to continuously write the power supply value it would be ideal to converge the timing for the watchdog and the power supplies, as they'll both be the hardwire timed task, but how can I know what output rate will act as a continuous supply of power? 

 

Any advice much appreciate, feel free to tell me analog would suit any of it better as I have the modules available.

0 Kudos
Message 1 of 9
(234 Views)
Solution
Accepted by Shiv0921

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.

Message 2 of 9
(225 Views)

[Edit: by the time I got around to answering this, BertMcMahan had already given such an excellent answer, none of my original writeup was worth posting.  Instead, I have only a couple things to add.]

 

Note: I too am only familiar with DAQmx, not the RIO FPGA or the use of the "Scan Engine".

 


@BertMcMahan wrote:

... 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.)

This may also depend on the module.  I'm pretty sure a Delta-Sigma based analog output would revert to 0 V output after the task is stopped.  And I don't think I've ever tried using one in software-timed mode, so I'm not sure that (A) it's possible or (B) whether the output value is held steady as long as the task remains active.  I also don't know which (if any) modules use Delta-Sigma for their analog outs, so this may be a moot point.

 


@BertMcMahan wrote:

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.


I know some of the cDAQ and cRIO modules can handle other digital logic levels besides 5V logic (such as 12V and 24V).

    But the main point here is correct.  To be "digital" does include the idea that only 2 values are possible, but not every combo of 2 values will be compatible with one of the digital logic standards.

     (Minor clarification for OP's benefit: where Bert says a digital line must output a 0 or 1 he's *NOT* talking about voltage.  Multiple digital lines are often output by writing an 8-bit integer to the port where each line is represented by a single 0 or 1 bit.  Basically, the 0 or 1 is just a reference to being logically OFF or logically ON.  Another way to turn a digital line OFF or ON is with a boolean False or True.  But down at the actual pin, the *voltage* will depend on the digital logic standard of that module, with 0-5 V TTL being a very common one.) 

 

 

-Kevin P

Message 3 of 9
(191 Views)

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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 4 of 9
(175 Views)

Thank you Bert, this answer was well written and illuminating, it's cleared up many confusions for me. Especially the watchdog, of course it needs to be hardware timed aha!

I definitely had also misunderstood that digital is only 0 or 5V (or others depending on module), though now it makes sense that of course it would be! So thank you for pointing that out. I'll have to have a look at what specific voltages we need output. 

 

 

0 Kudos
Message 5 of 9
(163 Views)

It's a cRIO-9045, the analog in is a NI-9205, analog out is NI-9263 and the DIO is a NI-9401. 

I thought I read that the cRIO-904x series have a sample clock per module, or that the c series modules do? But now that I'm looking again I can't find that, so am not sure now.

 

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.


 

0 Kudos
Message 6 of 9
(159 Views)

@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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 7 of 9
(155 Views)

@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.

0 Kudos
Message 8 of 9
(150 Views)

Yes, a cRIO-904x/905x has a DAQmx-ASIC on board - parallel to the FPGA chip, see here:

 

https://www.ni.com/documentation/de/compactrio-controller/latest/crio-9045/block-diagram/

 

Regards, Jens

Kudos are welcome...
0 Kudos
Message 9 of 9
(140 Views)