Jump to content

Automation of a Manual QSM


Recommended Posts

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

Link to comment

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.

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.