theoneandonlyjim Posted May 5, 2010 Report Share Posted May 5, 2010 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. 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? Quote Link to comment
jgcode Posted May 5, 2010 Report Share Posted May 5, 2010 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. 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. Quote Link to comment
PaulL Posted May 6, 2010 Report Share Posted May 6, 2010 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. Quote Link to comment
theoneandonlyjim Posted May 7, 2010 Author Report Share Posted May 7, 2010 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. Quote Link to comment
ASTDan Posted May 7, 2010 Report Share Posted May 7, 2010 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. 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 Quote Link to comment
Daklu Posted May 8, 2010 Report Share Posted May 8, 2010 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. (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...) Quote Link to comment
theoneandonlyjim Posted May 10, 2010 Author Report Share Posted May 10, 2010 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.