« | »

Introducing “Questions”

In the category “Questions” you can ask any question about Virtual Finite State Machines or about how to use StateWORKS development tools. Simply post a comment to this entry.

Tags: , ,

16 Responses to “Introducing “Questions””

  1. Gustavo says:

    I am evaluating StateWorks as well as other tools such as VisualState, and I think that
    SW may finally be my choice, but I have a couple of questions about some misbehaviors or limitations I have noticed up to this moment:
    1) I have one state in which I wait for some swip to detect that an NI reached some value, and I have a timeout in that point, so this state has en entry action that resets and restarts the timer, and two outgoing transitions, one on timeout and the other on the swip condition. If the timer is running when I enter the state (it doesn’t care in previous states) and it has a value over the timeout limit, then the timeout transition triggers at entry, like if the entry action were delayed. I think this may be because the timer may be implemented in the VFSM just as another VFSM and it takes a cycle to respond to the reset and restart command, but this is not what normally happens in my soft FSM’s because I use down timers and I reset and restart them simply by loading the timeout constant, which is done instantaneously. I solve it in SW by previously resetting the timer in other states, but in that way the model becomes some different from the implementation. I also tried with the _B_ prefix in that state but nothing changed.
    2) I red about the “~” button in the dictionary menus but it doesn’t appear in my LE version 6.2.0, and it should be useful because without it I have to combine IN and LOW outputs from a swip and the transition text becomes so long that it appears truncated in the diagram.

  2. Ferdinand Wagner says:

    Ad 1. The behavior of the state machine is correct. You find the explanation in our last Technical note “Break States in the VFSM Executor”. The execution cycle on Fig. 1 shows that the executor uses a copy of the virtual input until it terminates the cycle returning to the point “wait for VI change”. Thus, in your example entering the state where it is to wait for a swip or a timeout the Executor “finds” the timeout OVER and continues transitions.
    There are several workarounds for such situations, but the use of _B_ prefix is the correct solution.
    The _B_ prefix has been enabled since version 7.2. I presume that you are using an older version, therefore you have failed.
    Ad 2. Similarly, the completion operation has been introduced later and is not available in the LE version 6.2.
    Your questions refer to a general problem that we have with the LE version free available on our web site. It is getting relatively old but we hesitate to replace it with a newer version which is of course a much better one but does not correspond well to the book content. In the nearest future we are going to solve the problem.

  3. Gustavo says:

    Thank you Ferdinand,
    I will go on with my tests, it shall be nice to have the updated LE version.

  4. abdel says:

    sorry i dont speak english verry well but i have some qustion on state works.
    i’m trainee and i have a project on finit state machine.
    i search a tool who can do this applications.i evaluate some tools and i want knowledge if state works do it:
    1-stateworks can generate a code C from a model of FSM?
    2-state works can generate a documentation.
    3-state works can give a debug
    4-state works can give interface with the target?
    6-state works can manage the hierarchical automat?
    i wait your answer thank’s

  5. ferdinand says:


    1. No, we do not generate a C code. There is no use for the code in a StateWORKS environment. Or in other words: StateWORKS offers a standard execution code. We use a ready run-time system to execute the specification result. See the technical note “What is StateWORKS” and the book.

    2. Yes, StateWORKS Studio generates several documentation documents. The basic documents are XML files containing full information about the specified state machines and the execution model. In addition, there are several auxiliary files, like: state transition diagram, state transition tables, object list, etc.

    3. Yes, StateWORKS run-time system can be (logically) debugged. For debugging purpose we have two monitors SWMon and SWQuickPro. Debugging covers among others service (force) mode, tracing, debugging mode (run, step, hold), automatic testing by use of command files (prepared by hand or transformed from log files). See the technical note “Debugging State Machines” and “Testing with StateWORKS”.

    4. Yes, the interface to the target is a tcp/ip connection (the run-time system is tcp/ip server). The primary examples of a target interface are the monitors. See the technical note “Graphical User Interface for StateWORKS Run-time Systems” and “Using tcp/ip channels as an I/O interface”.

    5. If you mean retroengineering as revers-engineering it does not apply to StateWORKS specification: see the Answer 1.

    6. Of course, the specification of a hierarchical system of state machines is a major feature of StateWORKS. See the technical note “Hierarchical systems of state machines”.

  6. Joe says:

    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?

  7. ferdinand says:


    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.

  8. Dominique says:

    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?


  9. ferdinand says:

    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?

  10. 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.

  11. Dominique says:

    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.

  12. John M says:

    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?

  13. ferdinand says:

    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.

  14. John M says:

    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?

  15. ferdinand says:

    Exactly. The changes of the virtual input can be done by the I/O Handler and by the outputs of the executed state machine.

  16. ferdinand says:

    Unfortunately this blog does not allow to include diagrams. Therefore I can only described how it could be done. If it is difficult to follow send me your email and I will send you the project.

    We start with the sunny-day-scenario. This is realized using states: Closed, Opening, Opened and Closing. The specification of these states is more or less obvious.

    If we want to supervise the sensors Opened and Closed and generate alarms the same state transition diagram will do but the states itself are more complex.

    In states Closed and Opened the valve is correspondingly closed and opened.

    In state Opening and Closed sensors are tested. To realize it we use a Timer. If the timer expires in the state Opening a Coming AlarmFailedToOpen is generated and the state machine returns to the state Closed. The Alarm stays sharp until we repeat the test and the sensors generates a correct signal. In that case the the Going AlarmFailedToOpen will be generated and the Alarm is terminated.

    The state Closing is similar but the sensor Closing will be tested. Also in that case the AlarmFailedToClose stays sharp and will terminate if the sensor Closed generates correct signal. Sometimes we want always to go to the state Closed hoping that the Valve has closed anyway but the sensor is broken.

    This solution will be OK for a single state machine. Note that the state machine generates only alarms that are for the outside world (operator) but an alarm is not a logical information that can be used by other state machine. Also the information “all sensors are broken” does not exist explicitly. Of course an operator receiving both Coming alarms knows that both sensors are broken.

    A state machine that is going to be used in a system of state machines should have error states that signal for instance to a Master the erroneous situation.
    When I find time a will show a solution for such a state machine.

Leave a Reply

You must be logged in to post a comment.