Jump to content

Is QSM my best option?


Recommended Posts

I've got to communicate dynamically with several stations which carry out essentially the same operations, where the parameters are individually input by UI and operation by semaphore-controlled tool function.

Right now I've got the project set up as a QSM as seen in the attached photo.

post-17061-127309127475_thumb.jpg

The top level VI initializes itself, the subVIs and then is idle while the subVIs operate unless an error or stop command is passed. I find myself saving each subVI as a unique file in order to maintain operation of the state machine for each, rather than what seems logical - to place a single reentrant VI. This brings to light my question - is there a better option than a QSM?

Link to comment

I've got to communicate dynamically with several stations which carry out essentially the same operations, where the parameters are individually input by UI and operation by semaphore-controlled tool function.

Right now I've got the project set up as a QSM as seen in the attached photo.

post-17061-127309127475_thumb.jpg

The top level VI initializes itself, the subVIs and then is idle while the subVIs operate unless an error or stop command is passed. I find myself saving each subVI as a unique file in order to maintain operation of the state machine for each, rather than what seems logical - to place a single reentrant VI. This brings to light my question - is there a better option than a QSM?

You can make a FGV a reentrant VI, but because it contains persistent data (USRs) you use the preallocated option for reentrancy. Therefore, every instance placed on the block diagram will have a unique state.

That may help.

Link to comment

is there a better option than a QSM?

In my opinion, yes! It would change your approach a bit, but if you were willing to use Object-Oriented design patterns you could use a combination of the Command Pattern (in particular, you could include the target controller as an object inside the command, thus handling all commands for all controllers through a single--preferably asynchronous--message channel) and the State Pattern. You can create a Controller class and then create subclasses that inherit from this.

Link to comment

In my opinion, yes! It would change your approach a bit, but if you were willing to use Object-Oriented design patterns you could use a combination of the Command Pattern (in particular, you could include the target controller as an object inside the command, thus handling all commands for all controllers through a single--preferably asynchronous--message channel) and the State Pattern. You can create a Controller class and then create subclasses that inherit from this.

Ah, and there's the rub. I'm just now getting into LabVIEW OOP, and my skills aren't quite up to this level of a challenge. Maybe in a future rev. Thanks.

Link to comment

I've got to communicate dynamically with several stations which carry out essentially the same operations, where the parameters are individually input by UI and operation by semaphore-controlled tool function.

Right now I've got the project set up as a QSM as seen in the attached photo.

post-17061-127309127475_thumb.jpg

The top level VI initializes itself, the subVIs and then is idle while the subVIs operate unless an error or stop command is passed. I find myself saving each subVI as a unique file in order to maintain operation of the state machine for each, rather than what seems logical - to place a single reentrant VI. This brings to light my question - is there a better option than a QSM?

Check this out

http://forums.ni.com/ni/board/message?board.id=170&message.id=390557

I have used this architecture in some of my projects. I like this when I need to send message to dynamically running VI's

Link to comment

you could use a combination of the Command Pattern

I think I'm going to start calling you Commander Paul. Maybe I'll sponser an over-under line on how many posts you can go without mentioning the command pattern. wink.giflaugh.gif

(I jest. Your advice, as always, is always spot on!)

This brings to light my question - is there a better option than a QSM?

There's always a better option than a QSM.

(Not that I have an opinion about it or anything...)

Link to comment

Check this out

http://forums.ni.com...ssage.id=390557

I have used this architecture in some of my projects. I like this when I need to send message to dynamically running VI's

I love this idea. This would fit very nicely as a replacement to my current architecture and I can see where it would solve some code issues I have patched with duct tape and good intentions.

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.