@Kevin_Price wrote:
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.
Thank you for this. This is exactly what I was searching for and I didn't know where to look. I use atomic hanlders and MPI in java and c++, seems like labview has the same functions as small blocks... Thanks a lot Kevin....
