simple way to pass a signal between independant VIs

[stuart777]

Set-Up: I am using one VI (modfied version of http://www.ni.com/example/29872/en/) to output a voltage signal to a speaker using the NI 9263 module. This VI runs independantly and simply allows me to adjust amplitude and frequency as I acquire data. I am then using a second VI to read/save data from an array of 8 pressure transducers, this is a standard VI which uses DAQmx components to sample from two NI 9215 modules. 

Question: Is there a way to pass the waveform from the signal generating VI to my data acquisition VI? I would like to save it along side my data for processing later on. I could of course T-off the voltage signal and send it back into the input module, but this seems like a dumb solution. Thoughts? Simplest solution wins!

I can gladly obtain screenshots if people would like, but our lab PC is offline so I havent taken any yet. These really are simple straight forward codes right now, I'm hoping to make minimal modifications.

(I know I don't have any posts on here, but I will give Kudos/Select Answer)

EDIT: Even if you could just suggest functions/methods to look into, that would be helpful. I have the feeling I'm not using the correct vocabulary in my searches.

[Stuart.Parkinson]

You could use a queue. If you create a queue with a name in each vi then, if the name is the same, they access the same queue. Put data on it in one vi and de-queue it in the other.

This is kind of a inter-vi producer-consumer thing.

[VItan]

I would suggest using a Queue that is shared between the two VI's.

Obtain a Queue and provide a reference to the Queue to both VI's.

In the VI generating the waveform and writing it to your hardware driver, enqueue the waveform value.

In the VI that will log the waveform value, dequeue elements for logging.

[crossrulz]

Producer/Consumer

[VItan]

---

@Stuart.Parkinson wrote:

...

This is kind of a inter-vi producer-consumer thing.

---

This is actually a One-to-Many Producer-Consumer:

Producer:

Waveform generation logic

Consumers:

Hardware driver

Logging

Therefore using a queue is using two One-to-One patterns (generator-to-hardware and generator-to-logger) to satisfy the overall requirement.  Another solution would be to use a One-to-Many mechanism such as a User Event with multiple registrations: Have three VI's:

Waveform Generator: Generates a waveform and raises a User Event containing the waveform data

Write to Hardware: Callback for the User Event (just uses an Event Structure to wait on its registration of the User Event), writes the User Event's waveform data to the hardware driver

Logging: Callback for the User Event (just uses an Event Structure to wait on its registration of the User Event), writes the User Event's waveform data to the log

[stuart777]

Is it necessary that the enque'ed data and the dequeing process be done at the same rate? I am currently writing my voltage out at 20kHz (probably unecessarily high) and reading at only 4kHz.

[VItan]

---

@stuart777 wrote:

Is it necessary that the enque'ed data and the dequeing process be done at the same rate? I am currently writing my voltage out at 20kHz (probably unecessarily high) and reading at only 4kHz.

---

You do not need to perform enqueueing and dequeueing at the same rate, but you do need to maintain a total dequeueing data rate greater than or equal to the enqueueing data rate.

For example, you may enqueue one data point 20,000 times a second and then dequeue 20,000 data points one times a second.  However, if you enqueue on data point 20,000 times a second and then dequeue one data point one times a second, you will be continuously increasing the amount of data that is buffered in your queue.

[jcarmody]

If you don't care about losing the intermediate points, use a Notifier.

[Stuart.Parkinson · Accepted solution]

---

@VItan wrote:

This is actually a One-to-Many Producer-Consumer:

Producer:

Waveform generation logic

Consumers:

Hardware driver

Logging

---

One generator -> Hardware and to Logger - true....

But just one queue will do - only need it for passing data to the other vi (the hardware can be driven direct) so just a one to one queue.

Passing in event data is an interesting take on it though. Not tried that between vis before.

EDIT - actually just re-read your post. Thought you were saying the queue wouldn't work but I think I mis-read that. 🙂

[VItan]

---

@Stuart.Parkinson wrote:

...

But just one queue will do - only need it for passing data to the other vi (the hardware can be driven direct) so just a one to one queue.

Passing in event data is an interesting take on it though. Not tried that between vis before.

---

Actually, you aren't driving the hardware direct, you are interfacing to the driver and it is controlling the hardware.  The interface to the driver is a producer-consumer pattern where you produce data and write it to a buffer, then the driver reads from the buffer and performs the driving.  So we aren't actually escaping this One-to-One layer.

---

@Stuart.Parkinson wrote:

EDIT - actually just re-read your post. Thought you were saying the queue wouldn't work but I think I mis-read that. 🙂

---

Yup, it would work just fine.  I was just suggesting some additional ideas, such as the sketch below:

Each loop can actually be in its own VI, with the top level diagram being a top level launcher VI.  Spreading designs across VI's, including communication mechanisms, should never be a problem.  I've seen many people limit themselves by allowing a language construct, such as a VI, to limit them as the top level consideration with their actual design / pattern coming second; I believe that you should consider the design / pattern to be the highest / most pure form of what you are doing and not consider "a producer-consumer pattern" and "an inter-VI producer-consumer pattern" any different.