How to simultaneously run different executables on cdaq 9133

[123alex]

Hi

I have written separate executables for my cdaq 9133, using NI-9220 modules. I can only run one of the executables at a time. The first executable will work, the others will open, but not run. 

I'm reading voltage from different sensors on these.

I read that each module can only have one sampling rate. Even when the executables run on separate modules, I still can only run one. Ideally I'd have separate executables with different sampling rates and I'm trying to avoid creating one jumbo executables.

I've attached two of the executables and  VI's.

So ideally I would have all executables either combined into one with different sampling rates or have separate executables that can run simultaneously.

Thanks for any help you can offer.

Alex

[GHBIV]

Hi Alex,

I didn't spend a lot of time looking through your code - but what I did notice is that it doesn't look like you are using parallel while loops, at least in what appeared to be your main VI.

I think that using parallel while loops could allow you to limit your number of executables to 1 while still allowing you to use different sampling rates.  You aren't limited to just two parallel while loops, either.  You could use two loops to "produce" data at different sampling rates, pass that data through either queues or channel wires (depending on what version of LabVIEW you are using) to one consumer loop.  That loop can be used to either analyse or log the data.

National Instruments actually has a white paper discussing this technique:

Application Design Patters: Producer/Consumer - http://www.ni.com/white-paper/3023/en/

Let me know if that makes sense.

--GHBIV

[natasftw]

His problem is likely limited by clocks more than it is loops.  With 4 loops and a single clock, you have the same problem as one loop and a single clock.

You're also likely going to run into this with multiple executables.  Keep in mind you're asking all of them to use shared resources that are a part of the chassis itself and not the module.  If you can't do something within the single executable as a hardware limitation, it becomes less likely when you split the executables up as now you have even fewer resources to work with.

You'll likely want to look at decimation to resolve your issues

[Bob_Schor]

What are your sampling rates?  A slightly different question is at what rate are you getting new data?  [The distinction is that if you sample continuously 1000 points at 1KHz, your sampling rate is 1KHz, but you are only getting data at 1Hz, i.e. once/second you get 1000 points].

If the rate for getting new data is "reasonable" (i.e. a few Hz) and you take advantage of LabVIEW's natural parallelism, you can do a whole lot of stuff, with multiple sensors, streaming data to disk, updating scrolling displays, etc.  Here's an illustration:

I have a routine running on a dual-core PXI controller (8106), not the biggest speed demon out there.  My sampling loop runs at 1KHz (largely because I'm tracking some digital encoders that need to be "read" on a DIO port), but all this routine does is shove the data into an RT FIFO.  Though it runs every millisecond, it probably takes only 30-40 microseconds to "do its thing".  Meanwhile, there are other cores available ...

So every millisecond, an N-channel sample gets placed on the RT FIFO.  In one of my VIs asynchronously-running VIs, I have three loops running in parallel.  The first one is blocked waiting for something from the RT-FIFO, so it "wakes up" at 1KHz.  All it does is transfer the data from the RT FIFO to an ordinary Queue, as though it was the Producer of a Producer/Consumer pair.  However, what I really want to do is to wait until I have 50 such samples before I wake up the Consumer (so that my Consumer will run at 20 Hz, not 1KHz), so I count the number of packets and use a Notifier to "release" the Consumer when the count gets to 50.  What the Consumer does is to package up all the data and Network Stream it to the Host (where it gets displayed and saved).

That's two loops.  The third loop is reading a second RT FIFO that I didn't tell you about -- in my Timed Loop, I'm also monitoring some Digital Input lines, which most of the time "stay the same".  When/if any bit changes, I put the current DI information on a Digital Line FIFO.  My third loop is "waiting" for this information, and as fast as it comes in (typically on the average a few Hz), it is Network Streamed to the Host.

Meanwhile, there are other independent loops running asynchronously on the PXI, doing other tasks.  Because they tend to use LabVIEW's "blocking" mechanisms (like waiting and doing nothing if there's nothing in the Queue), there's a whole lot of "simultanous" code running (again, mostly "waiting to run"), and the system just hums along.  I've built a "clock signal" into my Sample Stream so that I can detect if I "miss" any samples due to "doing too much processing", and the answer is, "Not yet ...".

So the answer is to break things up into smaller loops that "do one thing" and to try to maximize parallelism.

Bob Schor

[natasftw]

Bob, can you explain how to use 18 RT FIFOs on your PXI?

[Bob_Schor]

I only have two RT FIFOs.  Let's say I have 18 channels sampled at 1KHz, with the results being an I16.  So one FIFO is a for an array, size 18, of I16.  I actually "mis-remembered" how the Digital Line FIFO was organized.  I have three sets of DI ports I monitor, one a 32-bit number, the other 2 8 bits.  I make a Cluster called DI Lines, and when any of the DI values changes, I update the Cluster and put it into the FIFO.  When the Consumer gets the data (again, at a very low rate), it looks at each of the three sets of bits, and whichever one(s) show a change, an "Event" (another cluster identifying the source, the time, and the data value) is Network-Streamed to the Host.

Sorry if I wasn't clear.

BS

[natasftw]

I'm aware you only have 2 setup in your application.

My question was more posed to point out you're answering something that isn't being asked.  The moment you brought up the PXI, you were discussing something entirely different.  While some things can be transitioned easily, that's not the case for all things.  His solution isn't as simple as "producer/consumer" or "use the native parallelism."  He's running into something that's a bit of a hardware limitation.

If he wants to take a look at different sample rates, he can't just offload and have the rate those loops update control things for him.  He'll have to do more beyond that to bring the rates down.  I have no idea what rates he's wanting to work with.  Some rates work well with a 1/n decimation.  Some won't. 

Is it possible to find ways around hardware limitations?  Yes.  But, it's unlikely to be something "simple."

[Bob_Schor]

Fair enough.  I tried to state my assumptions and background up front -- thanks for pointing out that my experience on the PXI platform doesn't translate well for the cDAQ.

Bob Schor

[natasftw]

If that came off as harsh, it wasn't my intent.  I was hoping to point out a hardware limitation of your platform so you'd be able to think in those terms.  Once you start finding ways to solve those limitations in PXI, you can use ideas from that to see how to bring them to the other platform.

Really though, you and I can dance around potential solutions but we're both going to make worlds of assumptions until the OP provides us with at least a few details.

[123alex]

Hello,

Thanks everyone for replying to this thread. I very much appreciate your time and thoughts. This post is several months old. I'm in the field this week, so I'll reply fully when I'm back in the office next week (starting 29th Sep). 

I believe that this is a hardware limitation problem that could be solved by decimating certain channels. Since I started the thread I have moved on to producer-consumer loops and queues, so it's nice to be reminded of progress!

Thanks all.