Comments for StateWORKS Blog http://www.stateworks.net StateWORKS blog about software engineering using virtual finite state machines Mon, 15 Feb 2010 08:02:50 +0100 http://wordpress.org/?v=2.8.4 hourly 1 Comment on Introducing “Questions” 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.

]]> Comment on Introducing “Questions” 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?

]]> Comment on Introducing “Questions” 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.

]]> Comment on Introducing “Questions” 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?

]]> Comment on Introducing “Questions” 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.

]]> Comment on Introducing “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.

]]> Comment on Introducing “Questions” 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?

]]> Comment on Introducing “Questions” by Dominique http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-320 Dominique Tue, 15 Sep 2009 11:22:27 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-320 Hello, I just bought the book because we are currently implementing FSM in our project for handling HTML objects in a web based application: behaviour of picklist/buttons/search fields on clic depending on the current state of the page (editing, viewing, inserting...) I bought the book for the metodology and found that you have a complete development platform. Is it conceivable to integrate it in an application where those webpage-UI elements are developped in objectoriented PHP/Javascript/MySQL ? That would be very usefull to us as the higher level behaviour of the application is "process like" and is not coded yet. Thus the hierarchical behaviour of the machines you describe is exactly what we are looking for. Your Client/server communication, from what I understand, is for "internal networks" using TCP/IP. How does it translate in a web-based environment? Thanks. Hello,
I just bought the book because we are currently implementing FSM in our project for handling HTML objects in a web based application: behaviour of picklist/buttons/search fields on clic depending on the current state of the page (editing, viewing, inserting…)
I bought the book for the metodology and found that you have a complete development platform. Is it conceivable to integrate it in an application where those webpage-UI elements are developped in objectoriented PHP/Javascript/MySQL ?
That would be very usefull to us as the higher level behaviour of the application is “process like” and is not coded yet. Thus the hierarchical behaviour of the machines you describe is exactly what we are looking for.
Your Client/server communication, from what I understand, is for “internal networks” using TCP/IP. How does it translate in a web-based environment?

Thanks.

]]> Comment on Introducing “Questions” by ferdinand http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-110 ferdinand Tue, 09 Jun 2009 17:41:12 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-110 Answers: 1. Yes, the run-time system executes the specification which contains a pure control (decision) logic, no data handling. Data parts are processed in separate threads. Ideally, you should extract the complete control logic from data processing that are realized in I/O-Handlers and Output Functions. In practice, in a demo or slow application simple operations like for instance to switch on/off a lamp can be done of course directly but in a serious application the vfsm executor must not be loosing time hanging in some time consuming output functions. 2. Yes, formally vfsm has contradiction with OOP. But actually these are different levels having little in common: StateWORKS operates at a higher level of abstraction than any programming language. Note that states can not be altered by any external software, but must obey the rules built into the FSM specifications. If you try to implement fsm on object level you just add this functionality to the class. It may help you to implement better a behavior of objects of that type. Unfortunately you have no chance to build a large control system containing several state machines. This explains a rather hesitant usage of state machines (mostly in the form of statechart) in object oriented design. There are a lot of discussions about this topic but if you are in such a project you will see the reality: some separated use of state machines to and fro but no concept of the entire control. The VFSM concept is based on a separation between control and data flow in the software and both flows can be programmed as a nice object oriented software. The VFSM run-time system is written in C++ and in consequence the application dependent IO-handlers and Output Functions are written also in C++. 3. Yes, I used LabView but many years ago. So, my opinion (a nice graphical toy for student exercises) is rather irrelevant. It may have changed a lot since then. Answers:

1. Yes, the run-time system executes the specification which contains a pure control (decision) logic, no data handling. Data parts are processed in separate threads. Ideally, you should extract the complete control logic from data processing that are realized in I/O-Handlers and Output Functions. In practice, in a demo or slow application simple operations like for instance to switch on/off a lamp can be done of course directly but in a serious application the vfsm executor must not be loosing time hanging in some time consuming output functions.

2. Yes, formally vfsm has contradiction with OOP. But actually these are different levels having little in common: StateWORKS operates at a higher level of abstraction than any programming language. Note that states can not be altered by any external software, but must obey the rules built into the FSM specifications.
If you try to implement fsm on object level you just add this functionality to the class. It may help you to implement better a behavior of objects of that type. Unfortunately you have no chance to build a large control system containing several state machines. This explains a rather hesitant usage of state machines (mostly in the form of statechart) in object oriented design. There are a lot of discussions about this topic but if you are in such a project you will see the reality: some separated use of state machines to and fro but no concept of the entire control. The VFSM concept is based on a separation between control and data flow in the software and both flows can be programmed as a nice object oriented software. The VFSM run-time system is written in C++ and in consequence the application dependent IO-handlers and Output Functions are written also in C++.

3. Yes, I used LabView but many years ago. So, my opinion (a nice graphical toy for student exercises) is rather irrelevant. It may have changed a lot since then.

]]> Comment on Introducing “Questions” by Joe http://www.stateworks.net/2009/03/introducing-questions/comment-page-1/#comment-109 Joe Tue, 09 Jun 2009 14:53:53 +0000 http://stateworksnet.cmarc.net/2009/03/introducing-questions/#comment-109 1. Vfsm run-time system executes the specification. And I guess it's some sort of abstract control logic centralization, right? In order to have fast running vfsm, I think time-consuming data-processing parts must be handled in separate running processes. Then, to what degree should I extract the control logic from data-processing processes to the specification if I use vfsm? 2. Similar as above. Object oriented programming seems to have data and it's related actions bundled together. And the vfsm idea seems to have some contradiction with OOP? 3. Have you ever used Labview? I have not. How do you think of Labview? 1. Vfsm run-time system executes the specification. And I guess it’s some sort of abstract control logic centralization, right? In order to have fast running vfsm, I think time-consuming data-processing parts must be handled in separate running processes. Then, to what degree should I extract the control logic from data-processing processes to the specification if I use vfsm?

2. Similar as above. Object oriented programming seems to have data and it’s related actions bundled together. And the vfsm idea seems to have some contradiction with OOP?

3. Have you ever used Labview? I have not. How do you think of Labview?

]]>