Speed at parallel procuder loops

[crossrulz]

---

@Hulk1978 wrote:

with this version i´m getting error -201426 at sample clock. vi. At least one device does not support tasks with multiple devices.

I think, it´s the temp sensor

---

That is possible.  But your USB6000 should be able to support the temperature measurement as well.  So try hooking your thermocouple to it.

[Yamaeda]

---

@Hulk1978 wrote:

Good morning,

with this version i´m getting error -201426 at sample clock. vi. At least one device does not support tasks with multiple devices.

I think, it´s the temp sensor

---

Having multiple devices in the same task is often problematic. Just create 1 task per device and read them both in the same loop.

/Y

[Hulk1978]

yes, but like mentioned in first post. the consumer loop is reduced to the speed of temp sensor.

[RavensFan]

No. You can't spread one task across multiple devices.  The image Gerd showed he had one device with 2 channels.

Have you tried what I said which is run a loop at a regular rate where you get all available samples (-1) on the two different tasks?

[crossrulz]

---

@RavensFan wrote:

The image Gerd showed he had one device with 2 channels.

---

Now I feel "cheated"...

Spoiler

Let's see how many people get the pun.

[RavensFan]

Doh!  Sorry Tim.  I must have just seen a message from Gerd in another thread and had his name stuck in my mind. 

[Hulk1978]

Hi,

sorry. I was out of office.

If i understood right, the only solution is to connect the temp sensor to USB6000 device?

A software solution with two devices is not possible?

[johntrich1971]

Take advantage of the timeout on your temperature queue in your consumer.

[Yamaeda]

---

@Hulk1978 wrote:

yes, but like mentioned in first post. the consumer loop is reduced to the speed of temp sensor.

---

Yes, if you have them in the same loop that's the result. That's inherant to dataflow. Having them in different loops won't really change your problem, as it's at its core a sampling speed issue.

So how will you handle different sample speeds? One solution is to have the slow one dictate the loop time and simply read all available samples on the faster one. What you do after that is dependant on your requirements, take the average of the faster one to get everything at the slower rate, or duplicate the slower one to have all at the faster rate (with the caveat that the slow system might be 'lying').

/Y

[cbutcher]

Something like this might work for you:

Here I make both measurements in the same loop, with an iteration speed of 1s. It makes the graph a little jerky, but there we go...

You could alternatively use the "-1" available samples, but then you have to construct the time arrays more carefully for an X-Y graph.

These were taken from two different simulated DAQ devices (indeed with one device, this fails with resource contention in most cases I'd guess - in that case, use two Virtual Channels in a single task, and unify the sampling rate).

If you want more than 1 sample/s for the slow rate, just change the time array to match the bottom acquisition (which is at 10Hz). Obviously if they have different rates, you need different time arrays to Index and Bundle.