From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
11-06-2017 06:21 PM
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.
11-06-2017 11:33 PM
You need to understand data flow. For your actual task, search for the key words: "LabVIEW producer consumer".
11-07-2017 06:16 AM
Sounds like what you really need is a State Machine.
11-07-2017 08:03 AM - edited 11-07-2017 08:06 AM
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.
11-07-2017 08:05 AM
@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.
11-07-2017 09:34 AM
@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.
11-07-2017 11:50 AM
@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.
11-07-2017 12:28 PM
@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.
11-07-2017 04:05 PM
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?
11-07-2017 04:56 PM
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.