Suggestions on reading UI events in 3 prodcuer 1 consumer design?

[arizzi12]

I'm looking for suggestions on how to best handle UI events (stop, start logging button, possible menu options, etc.) within the the following design:

producer loop: serial comm with proprietary control system

producer loop: serial comm with NI analog related hardware

producer loop: serial comm with heise pressure transducer

consumer loop: parse data/strings/responses from producer loops, updates UI (w/ parsed data, graph, DI/DO LEDs, etc.)

Perhaps another loop (events) to monitor UI events?

another suggestion?

Thx for your time and effort,

Anthony

[Tim_S]

I'm looking for suggestions on how to best handle UI events (stop, start logging button, possible menu options, etc.) within the the following design:

producer loop: serial comm with proprietary control system

producer loop: serial comm with NI analog related hardware

producer loop: serial comm with heise pressure transducer

consumer loop: parse data/strings/responses from producer loops, updates UI (w/ parsed data, graph, DI/DO LEDs, etc.)

Perhaps another loop (events) to monitor UI events?

another suggestion?

The answer is it depends. It depends on what everything else is doing, how fast it has to respond, and the requirements of the system and the systems it's hooked to (the serial links in this case).

You can perform UI monitoring in one loop and the other tasks in other loop(s). If you are going to receive messages and have to turn a response around in 1 second, then a single loop may be fine unless you have to always receive data and save data, which will block execution if the user has to interact with a file dialog box. (I phrased that awkwardly, but I think the idea is there.)

Tim

[Mark Smith]

I'm looking for suggestions on how to best handle UI events (stop, start logging button, possible menu options, etc.) within the the following design:

producer loop: serial comm with proprietary control system

producer loop: serial comm with NI analog related hardware

producer loop: serial comm with heise pressure transducer

consumer loop: parse data/strings/responses from producer loops, updates UI (w/ parsed data, graph, DI/DO LEDs, etc.)

Perhaps another loop (events) to monitor UI events?

another suggestion?

Thx for your time and effort,

Anthony

I think you're on the right track - all the producers (in their own loops) enqueue data and the consumer dequeues data from all in another loop and processes it. If the processing/saving/etc bogs down you have some buffering and don't lose data.The consumer loop should now publish the processed data on user events. Now, have another loop with an event structure that both responds to UI events (button clicks, text entry, etc.) and also registers for the user events generated by the consumer loop. The UI will update as quickly as the consumer supplies data on the user events and will also be responsive to user input.

Mark

[ShaunR]

Your proposal will work well. It''s a centralised system and is proven to work well on small scale apps

You could also consider a "de-centralised" system where each "module" (your serial thingies) is a producer AND consumer so that data can not only be streamed from them, but control messages can be sent to them.

Consider, for example, that your new UI module wants to stop one (or all) of the serial modules - a common requirement. In a centralised system, the responsibly for that lies with the messaging node (your consumer) since it is the only part that is aware of the "STOP" message. At that point, things can get ugly as the app grows since now it's no longer just a consumer (just processing data), it's also a controller - so the responsibility boundary becomes blurred.

In a decentralised system, you can (don't have to...but can) pass the message straight from the UI to one or all of the modules directly. It doesn't stop you having a centralised processing point for data being emitted from the modules. It's just a little more "modular" in terms of how everything can fit together.