01-02-2012 01:24 PM
For example, can I read AI signal from one card at 100 Hz/ch in program one, and read TC signal from another card at 1 Hz in program two at the same time? Will there be some sort of resource conflict?
01-03-2012 07:14 AM
Anyone?
01-03-2012 07:49 AM
Well the first thing is that you did not give the hardware that you are using. That would help the discussion along.
There are many ways to do this even if there are limitations on card access. You can sample everything at the fastest rate and filter or reduce the data on the channels that you do not need at the faster rate. I would think (without knowing your hardware) that you should be able to access different cards separately but that will depend on the system.
01-03-2012 07:55 AM - edited 01-03-2012 07:57 AM
The hardware is cDAQ-9188 Chassis with 9205 and 9213 cards. I've thought about the approach below, but this would require passing information between VIs. Not that this can't be done, I just feel it will be much simpler if the access to hardware can be parallel.
aeastet wrote:
Well the first thing is that you did not give the hardware that you are using. That would help the discussion along.
There are many ways to do this even if there are limitations on card access. You can sample everything at the fastest rate and filter or reduce the data on the channels that you do not need at the faster rate. I would think (without knowing your hardware) that you should be able to access different cards separately but that will depend on the system.
01-03-2012 10:37 AM
If you have the hardware, try it and see what happens.
My cDAQ is on order so I can't try it at this point, but I do not think you will be able to access the 9188 with 2 different programs.
I am guessing that the programs are on different machines, so you could use shared variables. Have the program with the 100 Hz/ch rate collect the data from the 9188 and have it publish the shared variables for the for the slower temperature readings you want. Or just combine the programs if possible. Without knowing the overall system/setups it is hard to say what the best approach might be.
01-03-2012 11:05 AM
Hi Pellet8,
That is possible but you have to keep in mind certain factors. First, remember that the DAQmx driver isn't capable of running multiple tasks of the same type simultaneously. What I mean is that, you are able to acquire different signals from various channels simultaneously but all that should be handled by a single task. Also, consider that your programs can not use the same resources simultaneously (i.e... Counters). Finally, for this application, what I would recommend is that you configure a single task that acquires the signals from the different modules on your chassis as needed and then run the two programs in one, perhaps one as a subVI of the other. Is there any mandatory reason why this programs must remain separated?
I hope this helps! Please let me know if there is anything else I can clarify.
Best Regards
Carlos O
Applications Engineer
NI
01-03-2012 11:23 AM
You could try to set up two tasks that are both set to one reading on demand. You would have to handle the read timing in your programs. You have to start a task, take a reading and stop the task so the other program can get its reading. While this can work - it is slow and if both programs attempt to read at the same time, one will get an error that the resource is busy.
Having one read function that makes the data available to other programs/processes is a far better solution.
Rob
01-03-2012 01:33 PM
@Robert Cole wrote:
You could try to set up two tasks that are both set to one reading on demand. You would have to handle the read timing in your programs. You have to start a task, take a reading and stop the task so the other program can get its reading. While this can work - it is slow and if both programs attempt to read at the same time, one will get an error that the resource is busy.
Having one read function that makes the data available to other programs/processes is a far better solution.
Rob
This is what I'm afraid of. The chassis actually has 5 cards, the 2 I mentioned above were just given as examples. The program also has 5 functions/sub-programs. While I could have programmed every functionality in one VI, and activite channels to be used on demand, I was exploring ways to avoid maintaining one big interface by breaking it into 5 pieces. Parallel access was just one of the ways I thought is the simplest, but it doesn't seem that this way is viable.
Maybe I should consider define a single task and use shared variables. A couple of questions: is a single task capable of acquiring data from different cards at different rates? There are digital output needed for program #3, does this complicates the use of shared variables.
01-03-2012 01:42 PM
As the product page clearly states, you can "Run up to seven hardware-timed analog I/O, digital I/O, or counter/timer operations simultaneously". To me, that implies that you can have one task running for one card and a completely different task running for another. A single task cannot run at different rates.