Plotting without timeshift for producer consumer pattern

[ShaneJ007]

Dear Labview Profis, 

My Application: 

I have two data acquisition devices. 1. A force sensor (Baud rate 9600) 2. output from an ESP32 microcontroller.(baud rate 500,000) Both are using visa commands for serial COM ports. And then, the data are plotted in a graph and also written to a text file. For a better sny. architecture, I used a Producer Consumer pattern. 

My Architechture:

2 producer loops for two devcies with visa reads and one consumer loops to plot and write to txt file. 

With the help of this forum I managed to get it up and running leaving one problem. 

PROBLEM:

As you can see in the graph, Force sensor seems to be working with less precision obviously due to baud rate and you can see a time shift in the two graphs. Is there a way that I can resolve this issue?

PS: I used a German version of Labview I managed to translate all the buttons for you. Hope you find no problem. 

Thank you very much in advance. Attached is a vi(2018 or 2015 version) + measurement graph

Best, 

Shane

[kaba2005]

Oh Dear...

that is not a good implementation of a producer consumer design.

You are running both Producer loops with different rates and without sync.

Consider creating one producer loop, which is collecting data from both devices. The serial read function can be syncronized by the error wire to read at the "same" time.

Regards

Kay  

[RTSLVU]

I don't have your version installesd so I can not look at your code but...

It sounds like you need to synchronize your data collection. 

Instead of two producer loops running independently. Use only one producer loop and take one data sample from each device at the same time and place it in the same queue with a timestamp.

[kaba2005]

attached you will find my suggestion as a sketch...

[ShaneJ007]

ok thnaks @kaba2005 Let me try that.

1. even the two visa reads are at two different BaudRates, then still it should be fine ? 

2. May I know why you have used shift registers to accumulate the error please?

Thank you. 

[RTSLVU]

---

@ShaneJ007 wrote:

ok thnaks @kaba2005 Let me try that.

1. even the two visa reads are at two different BaudRates, then still it should be fine ? 

2. May I know why you have used shift registers to accumulate the error please?

Thank you. 

---

1. Yes. (Think DATA FLOW) both VISA writes/reads will have to complete before the program can continue.

So the program HAS TO wait for the slower instrument to complete its response. (or time out)

2. It is common practice to use shift registers on the error and VISA resource wires. I am sure one of the pros here can explain exactly why

[billko]

---

@RTSLVU wrote:

---

@ShaneJ007 wrote:

ok thnaks @kaba2005 Let me try that.

1. even the two visa reads are at two different BaudRates, then still it should be fine ? 

2. May I know why you have used shift registers to accumulate the error please?

Thank you. 

---

1. Yes. (Think DATA FLOW) both VISA writes/reads will have to complete before the program can continue.

So the program HAS TO wait for the slower instrument to complete its response. (or time out)

2. It is common practice to use shift registers on the error and VISA resource wires. I am sure one of the pros here can explain exactly why

---

I'm in favor of this practice because:

1. in a FOR loop, you want to make sure that previous errors are propagated forward.  (In the case of a FOR loop, ALL wires that need to come out the other end - like references, for example - need to be in a shift register for the same reason.  If a FOR loop iterates zero time - and it can - the data from the left side never makes it to the right side, unless you have a shift register.)
2. For all loops in general, I prefer a shift register because all my "unexpected" error handling is in the beginning of my loop, like early versions of the producer/consumer design pattern.

[Kevin_Price · Accepted solution]

Well, I actually disagree with some earlier advice here.

I would continue to give each serial instrument its own loop so they can iterate at their own natural pace.  Some devices might stream at 10's of Hz, others at 1 or 2.  One device might need to do time-consuming reinit while the other should stream.  Etc.   Many reasons.

From there, I tend to follow a QMH pattern.  Both instrument loops act as data producers that push their data into the *same* queue.  My main loop is the consumer that receives data from *all* the various producers.

Within the main loop, I maintain a cluster of "state variables" that are held in a shift register.  Each instrument's data gets stored in its own special field of that cluster when received.  Some message becomes the "triggering message" that tells me to retrieve all the most recent data from my state variable cluster, then do my calcs and update my display indicators.

    In your case, I might simply let the serial instrument that delivers data more frequently (likely the one with higher baud rate, but not necessarily) act as the "triggering" message.  When you receive it, you combine that instrument's data with your previously-stored data from the other instrument, do your calcs and display updates.

-Kevin P

P.S.  Just noticed I was in on an earlier related thread with you.  Go back and see similar advice with more detail about the typical "string / variant" message cluster used in the QMH pattern.

[ShaneJ007]

---

@kaba2005 wrote:

attached you will find my suggestion as a sketch...

---

@kaba2005 : Since one of my sensors doesn't directly send values at VISA read. (It writes a value p to the device telling him to send data) I'm afraid that this would not work... please correct me if i'm wrong.. 

[Ben]

There is an esoteric option available using Waveform Data types and the two queues.

IN both Producer loops gather data and push updates to the consumer loop such that the update is a WF and the "T0" value is correct.

IN the Consumer pace the loop by watching for updates from the slower Producer and when an update is found from coming from the slower of the two Producers, use that update as WF with an Y array consisting of a single value and then purge the queue from the faster Producer and present that data to a chart. The WF Chart should plot the data based on the T0 and dt of the data and align the data from both sources appropriately.

Ben