LabVIEW
9205 resource conflict?
- last edited on by
Content Cleaner
You can only run one task per module in a cDAQ chassis. You will need to propagate the task ID wire between your VI's. It acts as a reference to the task that is running on the card. If you call Create Virtual Channel again, it doesn't pick up an existing task, it tries to create a new one.
I think you can technically use named channels to get around this, but you'd have to reference the same name, not different names. It would also help to post the code you're using.
I can't see your VI's as I'm in v18 (do a Save for Previous Version and I'll take a peek). Also I'd recommend using a project to organize things.
Without looking at your code I'm having trouble figuring out what you're doing. A trigger is typically used to say "OK, start acquiring samples after [event] happens", where [event] can be an analog voltage rising above a certain level, or a digital line going high, etc. Triggers can also be used to Stop acquisitions- say you want to save the previous 4 seconds of data when a trigger occurs. Or as Reference triggers, where you save the previous 4 seconds and the next 2 seconds, or whatever. (I may have my names wrong here but I believe that's right).
Having a task with *just* a trigger in it seems to not be super useful. If you need to be constantly analyzing data, then have a software event fire when the data does something specific (like crosses a threshold), can't you do it in your analysis loop? In other words if you're already analyzing the data, just use that to trigger your software event. You don't have to set up a second trigger dedicated to doing that.
If you need to have two separate channels on one device, you can just read both sets of data in your processing loop (you CAN have multiple channels in one task, that's not a problem at all) then display one (for your finite repetitive tasks) and analyze the other (for your trigger conditions).
Can you explain exactly how you'd like the program to work? I'm just having trouble following.
Ah, that makes sense. I have a few rambling thoughts- hopefully something will help.
Unfortunately you can't do multiple tasks per physical device, as the article said, but you can always split your acquisition and your processing into different loops. Look at some of the examples in the Example Finder and Project Templates to do a Producer-Consumer loop. This will let you pull in data in one place, then send half to a "slow" analysis routine and half to a "fast" limit detection routine. That way your slow routine won't interrupt the fast one (within the limits of Windows, a nondeterministic, non real-time system, of course).
For a point of reference, one project I did used a pair of cards sampling at 1,000,000 samples per second on both cards, doing some analysis in realtime, and saving the results of the data (I didn't store ALL of the data- I just detected a failure condition, and the response time wasn't critical like it is in your case). At any rate, a throughput of 2,000,000 Double values per second didn't peg the processor nor blow up my memory usage.
In your case, having a triggered task be detected by software will be fairly quick, but the trigger is more for the card than for Windows. The trigger will cause your acquisition to start very quickly on the card, but reading the buffer will be slower. I think you would be OK with just sampling the data and making a software decision, but it all depends on how fast you need to respond. 10 ms should be easily doable (I've done it before), but 10 µs will be impossible within Windows (you could do it with an FPGA device, like a cRIO, but that's a whole other can of worms).
Your idea to sample one at a time is good in theory, BUT there is a significant overhead associated with starting a transfer. In other words, transferring 1 point 1000 times is considerably slower than transferring 1000 points 1 time. You will need to find the right balance of immediate detection vs. bus speed. I usually try for a ~10 Hz buffer read, but 100 Hz is probably fine too (the actual amount transferred per buffer read can be quite high with no troubles). Faster than that you might get into OS issues and may not be able to keep up, but it's quite hard to say theoretically so I'd recommend just trying things and seeing what works. It'll depend on your RAM, USB bus speed, processor, hard drive, phase of the moon, your favorite color, etc.
Last, with multiple input cards (in the same chassis) you could theoretically have a digital output task set to start on an analog trigger, firing a digital signal to E-stop the cylinder, and all of that should take place only on the cDAQ chassis which would be quite fast, but you'd need a dedicated AI device for that.
