How to record data after time delay / transfer data between while loops

[austin_okstate]

I'm having trouble sharing data between while loops. The goal of my VI is to find the RPM on a fan using an optical encoder. Since my data acquisition device can only count pulses, I need to count the pulses from the encoder, wait a specified amount of time and then count again. by subtracting the two measurements I can get the number of pulses given a time frame. I then can get the RPM. I can get data inside the first while loop. But when I try to take that data and place it in a different while loop with the time delay, it wont transfer. Any help would be appreciated.

[Blokk]

You need to understand data flow. For your actual task, search for the key words: "LabVIEW producer consumer".

[crossrulz]

Sounds like what you really need is a State Machine.

[AllisonSCJ]

To expand the first answer a little:

You can use a data buffer that is initialized outside of both loops, with the reference passed to both loops

You can use a producer/consumer loop and buffer your data in the producer loop.

You then dump the buffer from the consumer loop when your expected wait time is hit.

As a reference for future projects regarding data between loops, check out Labview examples of Producer/Consumer loops, and master/slave loops. You can access examples from Labview at any time By clicking Help->Find Examples from within Labview.

[AllisonSCJ]

---

@crossrulz wrote:

Sounds like what you really need is a State Machine.

---

Wouldn't a state machine mean that OP is missing data when in consumption state? It seems that they want synchronous consumption and aquisition of data.

[crossrulz]

---

@AllisonSCJ wrote:

---

@crossrulz wrote:

Sounds like what you really need is a State Machine.

---

Wouldn't a state machine mean that OP is missing data when in consumption state? It seems that they want synchronous consumption and aquisition of data.

---

In the supplied VI, the OP is trying to do the math in the second loop.  What I am suggesting is to not have a second loop.  Get Count, Wait, Get Count, Do Math.  That sounds like a sequence of steps to be done in a simple state machine.

[AllisonSCJ]

---

@crossrulz wrote:

---

@AllisonSCJ wrote:

---

@crossrulz wrote:

Sounds like what you really need is a State Machine.

---

Wouldn't a state machine mean that OP is missing data when in consumption state? It seems that they want synchronous consumption and aquisition of data.

---

In the supplied VI, the OP is trying to do the math in the second loop.  What I am suggesting is to not have a second loop.  Get Count, Wait, Get Count, Do Math.  That sounds like a sequence of steps to be done in a simple state machine.

---

A get count, wait, get count, do math state would cause the OP to no longer gather data while waiting, or while doing math.

The wait period is a wait on the second loop while the first is gathering data, so it shouldn't be a part of the state set. Even then however, the device is still sending pulses while OP would be in the Do Math state; data would be missed. This is why a Consumer/producer loop may be a better solution, as data would be continuously buffered and ready for use until the vi is stopped. A state machine might lead to data loss.

OP is attempting to synchronously gather and consume data. This is not possible if these two actions are their own states in a state machine.

[crossrulz]

---

@AllisonSCJ wrote:

The wait period is a wait on the second loop while the first is gathering data, so it shouldn't be a part of the state set. Even then however, the device is still sending pulses while OP would be in the Do Math state; data would be missed.

---

It is a COUNTER.  It just counts pulses and give you the latest number when you ask it.  The hardware takes care of everything.  No data missed.  And nothing says you can't keep getting the count during the wait period.  The math part will be nearly instantaneous, so that is not really a factor.

Now if we were talking about actual DAQ data, then a Producer/Consumer would be the way to go.

[austin_okstate]

Thank you for the responses, but why can't I just take the readout from my channel and place it in a different loop and wait 5 seconds or so, and get the time delay number of pulses? Would placing the Ticks after time delay in a for loop solve the issue? 

[austin_okstate]

The Producer/Consumer loop seems to work, but I'm curious if you set the Prod/Con loop to run continuously? This function would have me click the Enqueue Element button each time I want a readout.