Passing the data to other while loop

[Bob_Schor]

• Never use a Stacked Sequence.  
• Almost never use a Sequence (use the Error Line to serialize your code).
• Do you mind losing some of your data produced in Loop 1?  If the answer is "Yes, I mind, I need all of the data to go to Loop 2", then you need to learn the Producer/Consumer Design Pattern, which requires a loss-less communication path between Loop 1 and Loop 2.  You are using a Notifier, which is "lossy".  Replace it with a Queue, which is (usually) loss-less.
• Don't frustrate us and waste our time by posting pictures of code.  We can't fully inspect the code, we can't modify it, we can't run it, etc.

Bob Schor

[Bob_Schor]

---

@Bob_Schor wrote:

Because of the Principle of Data Flow, LabVIEW can do things "in parallel", i.e. all three loops can run at the same time without explicit "clocking" (but all running at their own speed).

• Loop 1 is a Producer -- it is getting data from DAQmx (I'm assuming -- you failed to post code) and probably "wakes up" every 10 ms when data appear.
• Loop 2 is a "Consumer" -- it takes all of the data from Loop 1 and "does something with it" (but does it pretty fast, probably finishing within 10 ms.
• Loop 3 is a "Partial Consumer" -- it takes the current data from Loop 1, does a lot of processing, and doesn't worry about getting all of these data.
• To send data from Loop 1 to Loop 2, use a Queue, a loss-less means of transport between parallel loops.
• To send data from Loop 1 to Loop 3, use a Notifier, which is a "lossy" method of sending the "last" data put on the Notifier by the Producer.

One piece of Useful Information we get when you post your code is we can tell what version of LabVIEW you are using.  You didn't post, you didn't mention it, so I won't tell you about Stream Channel Wires and Tag Channel Wires ...

Bob Schor

---

I didn't mention it at the time, but I'll be talking about "Using and Abusing Channel Wires" at NIWeek 2019 (Monday afternoon).

Bob Schor

[altenbach]

---

@darknesspic wrote:

After I verify my code carefully,

---

As others have said, there is no way for us to really judge the overall code architecture, but lots of things just scream "this is not good!".

For example:

• "No.Rec" needs to be an integer (blue) and there is no need to read the local. You could just wire the output of "array size" to the indicator terminal.
• You control wires to the wait function has the wrong representation too.
• Why can't you use a 2D array for all the channel data? (e.g. do they have different length?)
• Not sure why you need to get a string representation of the "time" in two different ways in parallel right next to each other?
• You don't need to get the current time. If "format date/time string" has it unwired, it assumes the current time.
• Where are all the terminals???
• There is a !=0 primitive!
• Wouldn't one instance of the "2" diagram constant be sufficient?
• There are potential race conditions because you cannot guarantee that all local variables have been written in loop A before they are read in the other loop.
• ...

[darknesspic]

Sorry for late response, I just busy on the job

I attached the code.

[johntrich1971]

I have a few observations which will hopefully help to get you on the right path.

1. Instead of the local variable use a queue to pass your raw data to the other loop.

2. Why are you duplicating code and adding local variable to do so in your "Up counter and shift the data 0-6ch." code? Use a FOR loop with auto-indexing instead. I would do the same for the "Get time and average Ch0-5" code and your "Initail array to 0" code. You can put the data in the appropriate indicators after the loop.

3. You can use a single notifier to pass an array of data to the third loop - then index the array there.

4. No need to have a separate loop to plot data. Also, don't worry about changing to dynamic data - just feed the data directly.

5. Get rid of the stacked sequences. 

There are lot's of other things, but this is a good start.