Are two DAQmx tasks allowed on the same input?

[ashesman1]

Hi,

I am updating an old, large application.  As part of it I am incorporating what an external controller (PLC) used to do into the application that used to run on a PC and putting it all into a cDAQ.  I would like to not mess too much with the existing code.

To add the old PLC code I need to read and write digital inputs and outputs.  No problems there, all done and working.  It turns out that some of the other code also needs to read some of the inputs (they used to be wired to both the PC and PLC).

I would like to keep my PLC replacement code clean and isolated from the rest of the application (as that is how it operates in the real world).  I am OK with the other code reading the inputs where it needs to.  Also, the control code only reads the input when needed so can not provide an up to date value of the input at all times to external code.

What I dont know is if it is OK to have two separate DAQmx tasks pointing to the same input.  Or if that will cause problems?

Out of interest, how does one normally synchronise say a seperate control and measurmement task?

I could if I get stuck wire to two different inputs externally to the same sensor...

Thanks in advance

Ashley

[ashesman1]

To add to this...

I have confirmed it does not seem to work.  If I disable my control code the measurmeent code reads from the digital input.  If I disable the measurmement code the control code can read.  If they are both enabled, Only the control (as it runs first) can ever read from the digital input.

FYI.  the control code creates and starts DAQmx tasks at startup and holds them until shutdown as the IO is read and written often and sometimes at a high rate.  The measurement code creates a task, does its read and then destroys it as needed.

With my limited understanding I am thinking it may be best to just wire to two inputs!!! 

[GerdW]

Hi ashesman,

NO, you cannot have two DAQmx tasks using the very same input…

With my limited understanding I am thinking it may be best to just wire to two inputs!!!

You should look into producer-consumer scheme. Or you could use a state machine. Or you could use a queue-driven approach…

There are a lot of possibilities, to handle your problem. Create one place, where the DAQmx task is handled - and other routines, which request new data from your DAQmx device or write to it…

as the IO is read and written often and sometimes at a high rate.

How (and why) do you write to a "digital input"?

[ashesman1]

Hi,

Thanks for your help.  We have decided to wire two inputs.  We can also see a situation where two different sensors could be used which sealed the decision.

I ended up using a RT Fifo to convey my trigger signal back from the timing code to the measurment code.  Seems to all work well on the bench!

Regards

Ashley

[GerdW]

Hi Ashley,

why do you use a "RT FIFO" when you work with DAQmx on cDAQ/PC?

[ashesman1]

I dont know.  I read in the documentation that it was appropriate for synchronising time critical sections of code!  All the code runs on the cDAQ.  No PC is involved (except for development).  The control code triggers a measurement sequence when a certain event occurs by posting an event (actually just a boolean) to a RTFifo.  The measurment code is blocked on the RTFIFO waiting for the event to trigger the measurement sequence.

Is that the wrong way to do it?

[GerdW]

Hi ashes,

Is that the wrong way to do it?

All I can say is it is wrong to talk about some code without seeing it…

Mind to attach your VI(s)?

[ashesman1]

Unfortunately to show this I would need to give the three main VIs that contain the bulk of the IP in the application so not allowed!  I appreciate your ability to reserve judgement without looking first!

[MarkCG]

Sounds like you are using one of those standalone cDAQs that run Windows embedded here. Just an opinion here but a cRIO might be better for this application. You are replacing a PLC and cRIOs work more like a PLC than a cDAQ. Using scan engine variables you don't have to mess around with DAQmx, running those task wires around and so on. You access the scan engine I/O variables directly from where you need to.

[ashesman1]

Using a cDAQ-9132.  Runs Linux.  It is a good part for the job I think other than the non intuitive DAQmx interface.  I have everything up and running now, looking forward to testing on a new machine next week.