Comments on: Introducing “Questions” http://www.stateworks.net/2009/03/introducing-questions/ StateWORKS blog about software engineering using virtual finite state machines Wed, 15 Sep 2010 17:51:43 +0200 http://wordpress.org/?v=2.8.4 hourly 1 By: John M http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-1454 John M Tue, 30 Mar 2010 04:48:21 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-1454 I see what you mean about increasingly diminished comprehensibility. (I have enough trouble remembering the scenario of a controller watching a panel of instruments and taking actions iteratively and in a possibly non-linear / sequential manner. The 'sequential programmer' nature runs deep!) A changeable execution engine would be unworkable! To move to a Moore model, an input condition of the Mealy (mixed?) model would be tested in a transition condition and if True the to-state entry actions would execute the input actions? I'll take a look at it - thanks. I see what you mean about increasingly diminished comprehensibility. (I have enough trouble remembering the scenario of a controller watching a panel of instruments and taking actions iteratively and in a possibly non-linear / sequential manner. The ’sequential programmer’ nature runs deep!) A changeable execution engine would be unworkable!

To move to a Moore model, an input condition of the Mealy (mixed?) model would be tested in a transition condition and if True the to-state entry actions would execute the input actions? I’ll take a look at it – thanks.

]]> By: ferdinand http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-1415 ferdinand Sun, 28 Mar 2010 08:50:59 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-1415 The present VFSM execution model is a result of several years of discussion and practical experiences. Your ideas could be implemented but there is one basic difficulty: the comprehensibility, especially if the model could be changed at any time. We allow it with the break state but we use it with care. Imagine that you have several possibilities to change the model according to problems you presented. The state machine will become as difficult to read as a coded implementation. I believe you should just use a simple model like a a Moore one to solve your problem. It will increase the number of states but you will understand what you are doing. The combination of Moore and Mealy model seems to be attractive but all experiences show that the design becomes complicated in spite of less states. The present VFSM execution model is a result of several years of discussion and practical experiences. Your ideas could be implemented but there is one basic difficulty: the comprehensibility, especially if the model could be changed at any time. We allow it with the break state but we use it with care. Imagine that you have several possibilities to change the model according to problems you presented. The state machine will become as difficult to read as a coded implementation.
I believe you should just use a simple model like a a Moore one to solve your problem. It will increase the number of states but you will understand what you are doing. The combination of Moore and Mealy model seems to be attractive but all experiences show that the design becomes complicated in spite of less states.

]]> By: John M http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-1364 John M Thu, 25 Mar 2010 06:19:18 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-1364 Technical Note 25 re "break states" looks very useful! I am wondering whether the idea could be applied to each transition rather than all the transitions from the _B_ tagged state? Anyway, how about the similar idea of a state change that executes the input actions of the to- state rather than the entry actions - or maybe the entry actions then immediately the input actions before the transitions? I'm trying handle 2 disjoint sets of logic via a "switch state" - rather than have a single state and pre-fix every condition expression with either "LogicSwitch_HIGH" or "LogicSwitch_LOW". So the switcher state has only transitions to either a LogicHigh or LogicLow state. Now the 'real' stuff in those 2 states is in input condition /actions but to execute those I need to make some kind of "change VI just to get input actions to execute" entry action .... and also make sure none of the LogicXxxx state transitions trigger until I want them to (ie after the input actions have executed). Some kind of "let transition to- state handle the latest VI change" transition would make life easier .... or is there another better way to handle this? Technical Note 25 re “break states” looks very useful! I am wondering whether the idea could be applied to each transition rather than all the transitions from the _B_ tagged state?

Anyway, how about the similar idea of a state change that executes the input actions of the to- state rather than the entry actions – or maybe the entry actions then immediately the input actions before the transitions?

I’m trying handle 2 disjoint sets of logic via a “switch state” – rather than have a single state and pre-fix every condition expression with either “LogicSwitch_HIGH” or “LogicSwitch_LOW”. So the switcher state has only transitions to either a LogicHigh or LogicLow state.

Now the ‘real’ stuff in those 2 states is in input condition /actions but to execute those I need to make some kind of “change VI just to get input actions to execute” entry action …. and also make sure none of the LogicXxxx state transitions trigger until I want them to (ie after the input actions have executed).

Some kind of “let transition to- state handle the latest VI change” transition would make life easier …. or is there another better way to handle this?

]]> By: ferdinand http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-933 ferdinand Mon, 15 Feb 2010 08:02:50 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-933 Exactly. The changes of the virtual input can be done by the I/O Handler and by the outputs of the executed state machine. Exactly. The changes of the virtual input can be done by the I/O Handler and by the outputs of the executed state machine.

]]> By: John M http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-930 John M Mon, 15 Feb 2010 03:37:54 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-930 Thanks - must confess I was thinking single state machine only. I suppose in any case one needs to be aware of the principle of *continuous* monitoring of inputs? The input values to even a single state machine could change in the middle of control logic execution - yes? Thanks – must confess I was thinking single state machine only. I suppose in any case one needs to be aware of the principle of *continuous* monitoring of inputs? The input values to even a single state machine could change in the middle of control logic execution – yes?

]]> By: ferdinand http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-888 ferdinand Wed, 10 Feb 2010 12:54:56 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-888 John, Yes, there is a reason for this solution. While the Executor is processing a state machine the virtual input of this state machine may change. Thus this state machine will be put into Executor queue. If the Executor uses the virtual input (and not the copy) the situation will be ambiguous. For a single state machine it is irrelevant. For a system of a state machine we get a different behavior. Thank you for a comment to this quite sophisticated issue. John,
Yes, there is a reason for this solution. While the Executor is processing a state machine the virtual input of this state machine may change. Thus this state machine will be put into Executor queue. If the Executor uses the virtual input (and not the copy) the situation will be ambiguous. For a single state machine it is irrelevant. For a system of a state machine we get a different behavior.
Thank you for a comment to this quite sophisticated issue.

]]> By: John M http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-885 John M Wed, 10 Feb 2010 01:12:02 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-885 Ferdinand - Wrt comments 1 & 2 (Gustavo & your response in March '09 re control logic execution sequences and 'break states') : is there an inherent and strong reason that a copy of the VI with values at entry is used throughout the whole sequence of execution to "no more transitions"? Sure the alternatives beg the question of when a control values change where to loop back to in the condition evaluation sequence (and doubtless would allow for creation of nasty little in-state loops). Possibly there is no good answer to this question? Ferdinand –
Wrt comments 1 & 2 (Gustavo & your response in March ‘09 re control logic execution sequences and ‘break states’) : is there an inherent and strong reason that a copy of the VI with values at entry is used throughout the whole sequence of execution to “no more transitions”?

Sure the alternatives beg the question of when a control values change where to loop back to in the condition evaluation sequence (and doubtless would allow for creation of nasty little in-state loops). Possibly there is no good answer to this question?

]]> By: Dominique http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-331 Dominique Wed, 16 Sep 2009 12:35:53 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-331 Mike, Ferdinand, Thanks for the quick reaction. That's what I was hoping for, we could run the exe on our hosted server. I guess now we have to finish reading the book and download the software to test it. I will probably contact you then if we have any questions. Mike, Ferdinand,
Thanks for the quick reaction.
That’s what I was hoping for, we could run the exe on our hosted server.
I guess now we have to finish reading the book and download the software to test it. I will probably contact you then if we have any questions.

]]> By: Mike Tommasi STATEWORKS http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-323 Mike Tommasi STATEWORKS Tue, 15 Sep 2009 12:58:30 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-323 Ferdinand, thinking out loud: maybe it could work like this: Dominique defines behaviour of web application using Stateworks, obtains the executable data file, uploads it to a server , then we make a PHP class that he can run on his host to send via TCP/IP all requests (page and HTML object state), and get the result. The Stateworks server could even be a dedicated remote server that we could host, something secure in a suitable colocation rack, maybe on our stateworks.com hosting service. This avoids him having to worry about how to run an exe somewhere. Ferdinand, thinking out loud: maybe it could work like this: Dominique defines behaviour of web application using Stateworks, obtains the executable data file, uploads it to a server , then we make a PHP class that he can run on his host to send via TCP/IP all requests (page and HTML object state), and get the result.

The Stateworks server could even be a dedicated remote server that we could host, something secure in a suitable colocation rack, maybe on our stateworks.com hosting service. This avoids him having to worry about how to run an exe somewhere.

]]> By: ferdinand http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-322 ferdinand Tue, 15 Sep 2009 12:42:57 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-322 It is obvious that you can use StateWORKS development tools to specify your control problem and to test it. The answer to the “implementation in the web environment” question is more difficult. Our run-time system is an EXE running under Windows (or Linux) operating system. The communication with the system is done using tcp/ip as the run-time system is a tcp/ip server. So writing a client you can access the system. Originally the client server application has been developed for User Interfaces and other monitoring purposes. “Classical” industrial control applications need I/O handler to communicate with the run-time system. A web application is a kind of User Interface. You can have a look at our case study "Calculator" that shows this kind of example (which is probably even more complex due to the calculations that require Output Functions). As you can access all object in the run-time system you can realize a control using our standard executor without writing I/O Handler or Output Functions. The question is where will the EXE run? It is obvious that you can use StateWORKS development tools to specify your control problem and to test it. The answer to the “implementation in the web environment” question is more difficult. Our run-time system is an EXE running under Windows (or Linux) operating system. The communication with the system is done using tcp/ip as the run-time system is a tcp/ip server. So writing a client you can access the system. Originally the client server application has been developed for User Interfaces and other monitoring purposes. “Classical” industrial control applications need I/O handler to communicate with the run-time system. A web application is a kind of User Interface. You can have a look at our case study “Calculator” that shows this kind of example (which is probably even more complex due to the calculations that require Output Functions).
As you can access all object in the run-time system you can realize a control using our standard executor without writing I/O Handler or Output Functions. The question is where will the EXE run?

]]>