Merging data streams from multiple sources

[xl600]

I have a RT loop that samples a 1 element RT queue at a specific frequency.  The queue is used to hold the 'current' sample of a very jittery data input (Coming from a UDP packet).  This input represents many 'channels' worth of data and does not come from anything I have control over so I have to take it as-is.

The RT loop is an attempt to convert this into a waveform suitable for plotting in a waveform chart.

It works great...

But now, I'm asked to add analog sample data (From DAQmx tasks) to those charts.

Since the RT loop samples will be generated at a very slighly different rate (100Hz RT loop) than the analog data (1kHz resampled to 100Hz) due to RT loop clock vs DAQmx clock, I'm wondering what the best methodology is for combining all channels into a single (multi channel) waveform or data stream with minimal latency that I can send over a network stream?  Is there a common design pattern for this?

Thanks,

XL600

[Bob_Schor]

You mention an RT Loop, which I take to mean you are running LabVIEW RealTime on a Real-Time platform.  The whole point of Real-Time is time determinism, which (to me) implies that exactly the same clock runs the RT Loop as runs the DAQmx routines.  That being the case, if your RT loop is running at 100 Hz, you should be able to set your DAQ device to sample (continuously) 10 samples at 1KHz and synchronously read those 10 samples every "tick" of your RT loop.  If you are plotting everything, I'd average the DAQ samples so that all the plotted data comes in at the same 100Hz rate.

We actually had the opposite situation -- our DAQ/Sampling loop ran at 1KHz, but we had another piece of equipment running completely asynchronously that ran at about 120 Hz.  As the slower 120Hz data was acquired, its latest value was provided to the faster 1KHz loop which simply used the "latest" value, effectively "over-sampling" the slower channel.  Worked great.

Bob Schor

[xl600]

I set my daqmx devices to use the same 10mhz reference clock so their sample are aligned and synchronous.  That helps quite a bit.  But is the RT clock really shared?  I guess I'll have to try that out.  If I see no slew, I'll be very happy indeed.

the design doesn't combine analog sampling with the unique udp data sampling so I use separate loops, one a RT loop at 100hz reading the udp 'latest' value and the other a normal 10 hz while loop pulling 1khz samples from the analog cards and re sampling to 100hz.  Both push their channel data into queues which I then read in my merging vi.

you mention averaging of samples to ensure plotted data comes in at a unified 100 hz?  I'm not sure I understand what you mean there, regarding multiple streams of samples.

Thanks!

[crossrulz]

---

@Bob_Schor wrote:

The whole point of Real-Time is time determinism, which (to me) implies that exactly the same clock runs the RT Loop as runs the DAQmx routines.

---

Not really.  An RT OS is much like Windows, just has a more deterministic clock to run the CPU.  But the determinism is really only true if you are using a timed structure (Timed Loop stating that a process will occur every Xms with little jitter).  I haven't tried it, and I have not used DAQmx with RT (cRIO is better IMHO), but I am fairly certain you can use the DAQmx clock to set the rate of your Timed Loop.

[xl600]

While the timed loops don't use the same clock ck, they can be tied to a daqmx source using the daqmx create time no source vi.  My problem is that this consumes a counter in my day card which I don't have available.  Hence my desire to figure out an all software way to balance the sample streams.  I suspect they will operate at very nearly the same average rate but not exactly with the clocks not being tied together as suggested.

[Bob_Schor]

What is your hardware?  On what system is LabVIEW RT running?  Do you not have a separate Hardware Timer available, separate from the one on the (unnamed) "DAQ" card?  What is this mysterious card?  It is really difficult to suggest how to do something on a system when we are wearing blindfolds and earplugs.

Bob Schor

[xl600]

Pixe-8135RT

pxi-6281

pxi-6683h

my 6683 may be of some use here, but you can't create a timing source for a RT loop via NI-SYNC.  I sure wish I could, since I tie my 10mhz to the 6683 and the daq card.  A 100hz clock task from that will be locked to my daq timing.

My daq counters (2) are tied up, but I may be able to shift one over to the 6683 since it can timestamp pxi triggers and routed daq Pfi lines.  I'll have to think about that approach a bit.

I did do a test today with the RT loop and didn't see any obvious drift.  I'll rig it for a longer test tomorrow, but if it can keep the drift to < 1 sample per hour, I'll meet my requirement and my concern here goes away.  If I can't detect any drift, I'll probably ask NI to explain how the RT clock of the 8135 is so close to the 10mhz ref clock of the pxi backplane.