Passing front panel values to consumer loop for file header

[ConnerP]

Sooo after a computer freeze I will try to make this post again...

I am working on refactoring some inherited software and have a question I have been mulling but haven't reached a good conclusion. I am currently not sure if I am able to post the VI or not, regarding NDA and whatnot.

The main points are a producer/consumer with an event structure in the producer. The consumer is a state machine with basically 2 states-- idle and measure/analyze/save. Previously, there was a master cluster bundled at the start of the measurement state using a mix of local variables and control terminals. I was able entirely eliminate this by moving instrument settings into action engines which get their settings updated in the event loop when they change.

However, when saving the data, we need to build a header for the files and for this, I need front panel values. Currently I am wiring a few local variables directly into the subvi which handles saving. This works, but it seems out of place in the model and I am wondering if there is a better way to handle it.

I have considered a few solutions
1) Go back to having a master cluster in the consumer which goes through a shift register and is update as needed. This results in a lot of P/C overhead though.
2) Keep the pertinent FP values in a FGV or even normal global which I can call directly inside the saving subvi. This is better than #1 imo, but really goes against data flow.
3) From within the saving subvi, extract the values from the device action engines
4) Use a User Event to pass the data into the Event Loop and handle saving there. The downside here is creating a copy of the data which seems really over the top for this
5) Just live with the local variable calls as they are.

I hope I made the situation clear enough without a diagram. I know there typically isn't a 100% correct solution for every design problem, but I'm hoping some of you more experienced LV programmers out there might have some ideas.

Thanks for all the time you regular posters put in to help us amateurs!

[Bob_Schor]

Can you write a tiny VI that demonstrates the Problem?  I'm assuming the issue is that the Front Panel Values that you need to write might change, so you need "the latest values" (but why not simply wire the Front Panel Controls to the VI that does the writing?).  Obviously, there are some subtleties here that I don't "see".

A technique I've used with a Message Handler model (similar, I think, to your Producer/Consumer/State Machine) was to "add a State" called, say, "New File" that "fired" when the File Control was changed and passed the New File (in the Data part of the Message) into the MH where it was saved in a Shift Register.

[I recently did a 4.5 hour workshop for some colleagues I pretentiously called "Advanced LabVIEW Workshop", and one asked me "Why do you have so many Shift Registers across the top of your Message Handler instead of a Cluster?", to which I said "I like the pretty colors of the wires" (or something like that ...)].

Bob Schor

[ConnerP]

Hi Bob,
I put together a quick example to show you the general layout. Sorry it is not executable-- I really had to throw it together quick to mimic something more complex just to create a visual.

The values for the header -do not- change between starting the measurement and writing the file. As I was getting ready to type this message, I thought of another solution that may also work: create the header in the event structure where the measurement is started and pass that along in with the variant which tells the loop how many times to run.

I hope this was clear enough.

Thanks.

[crossrulz]

I would use another loop just for the logging.  This way it can happen while the data is being analyzed.  It would just be another simple QMH.  Use a queue with a data type of a cluster with a string (or enum, to tell the QMH what the message is) and a variant (to hold the message data).  Then you can have your main loop send a message to the logging loop to start a new log file and write the header data (included in the Variant).  The analysis loop can then use the same queue to send the data to log using a different string value and the data stored in the variant.

[drjdpowell]

---

@ConnerP wrote:
1) Go back to having a master cluster in the consumer which goes through a shift register and is update as needed. This results in a lot of P/C overhead though.

4) Use a User Event to pass the data into the Event Loop and handle saving there. The downside here is creating a copy of the data which seems really over the top for this

---

Just a suggestion, but get rid of the "Producer" if it is doing nothing but forwarding event information to the Consumer.  Put your event structure in your "Consumer".  Then there is no P/C overhead at all and your data is in the same loop as the events.

[ConnerP]

---

@drjdpowell wrote:

---

@ConnerP wrote:
1) Go back to having a master cluster in the consumer which goes through a shift register and is update as needed. This results in a lot of P/C overhead though.

4) Use a User Event to pass the data into the Event Loop and handle saving there. The downside here is creating a copy of the data which seems really over the top for this

---

Just a suggestion, but get rid of the "Producer" if it is doing nothing but forwarding event information to the Consumer.  Put your event structure in your "Consumer".  Then there is no P/C overhead at all and your data is in the same loop as the events.

---

The actual program is more complex. The event structure needs it's own loop because we need to be able to interact with the UI while data acquisition, processing, and plot updates (~10x/s) are happening.

[drjdpowell]

---

@ConnerP wrote:

---

@drjdpowell

---

The actual program is more complex. The event structure needs it's own loop because we need to be able to interact with the UI while data acquisition, processing, and plot updates (~10x/s) are happening.

---

Long-running processes like data processing might belong in a separate loop, as might semi-independent processes like data acquisition, but the UI is generally a set of short-running actions, intimately dependant on the thing it is a UI for.  Also note that users won't notice delays of 50  ms in UI response, and that is a long time to a computer.