Automation of a Manual QSM

[Dragoon235]

Hello,

I have an application that controls several pieces of equipment, and the basic architecture is a QSM-PC for each device. User button presses (interactions) are logged into an event structure which generates commands and loads them onto the respective queues. As an experiment, I tried implementing the system using the statechart module (if anyone is interested).

After this initial development stage, I need to add some automation to the system. Some of the automation is data driven, as in , when a device reports back a new data value. Other events are temporally triggered, such as acquiring a new video frame from from a framegrabber (no strict timing requirements). My goal is to have this system automation turned on or off with one (or a series of) button(s) on the manual control GUI.

My first thought was to set some of the timeout values on the dequeue to take care of the temporal servicing, and to rig an event structure to watch for new data for data driven operations. However, I would think that since I already have the messaging framework in place, and all necessary actions already have designated messages (take measurement, return data, report status, etc.), would it be possible to centralize this control? Does anyone have any suggestions for this type of automation?

Thanks,

Jonathan

[Daklu]

If I'm understanding correctly, your top-level vi is an event based producer consumer which sends messages to device-specific vis running in their own threads, each of which is implemented as a QSM-PC. Furthermore, each device may generate its own events the top level vi needs to react to. Is that correct?

Assuming that's correct, one option is to insert a Mediator class between the UI class and all the device classes. (After you refactor you device-specific vis into classes. ) Your UI and device classes communicate with the mediator instead of directly with each other. The purpose of the mediator is to sit around waiting for a message. When one arrives it forwards the message to the appropriate destination class. Each class can subscribe or unsubscribe to events/messages by notifying the mediator, which keeps a master subscription list.

[Dragoon235]

Thanks for the response, but I'm not sure that's what I need.

Maybe I should provide a little more elaboration. My question was not about message sending framework, as you have described in a pub/sub pattern. The statecharts are being used in place of an LVOO class, and there is not adequate time to re-factor the entire system design to use LVOOP. My goal is to design an extension module with minimal modification to the currently working code. My question was more about how would you specifically implement a message sender that responded to temporal triggers and data triggers. I'm not opposed to wrapping it in a class, but that is not of prime importance for this design. I will admit that I don't have much experience with LV classes.

Thanks again,

Jonathan

[Dragoon235]

I just realized one other thing I needed to clarify, this module needs to generate the temporal triggers. There is no external module generating them. Perhaps that is where the confusion with the pub/sub framework arose?