coder . cl

ProView provides a nice I/O API. All devices are controlled through a pair of API calls for reading and writing data from signals. You cannot use channels directly, so every channel should be bound to signals for I/O. All write requests are made using io_write and read requests are made using io_read, where both methods have their context in the ProView application. All devices that should be controlled through any ProView application should use the Process flag set to User2 with value 8. The problem is how to deal with I/O calls centralized in two API calls rather than using device specific I/O calls. Your code should be consistent enough to support that I/O method.

I need to work with a hierarchical state machine. The main problem that I am currently facing is how to pass messages or trigger events on each event transition. Since I am using C Plus Plus, I will use class methods. In this case, I will use a hardware device class method. On each state transition, an event will be thrown, and the given event should trigger an action — in this case a class method — that will complete the state transition. The advantage of the hierarchical state machine is the fact that you can manage composite hardware devices without problems, because each sub-device can be handled individually with its own state, but increases the complexity of the program.

The basic definition of a state machine is a set of states S, with a subset of initial states I, another subset of final states F, and a set of transitions between states T, and every state s’ ∈ S ∧ s” ∈ S where I ⊆ S ∧ F ⊆ S, and each element on T { s’, s”, h }, with s’ as the current state, s” as the next state and h as the state action. On my current automation project where I am using ProView, I have each device controlled by state machines, and each user or automatic control request is queued on a priority queue, where the highest priority is executed replacing any previous execution state, because we have only one communication channel. So the basic state machine definition is not enough to hold every environmental variable that we are using to control each device.

We are doing pretty good advances on the ICS/DCS that we are doing. The current code base is using the STL std::priority_queue as operation request queue, but we are changing the task request priority each time that the communication channel is being used by any transition that requests the Profibus channel. We cannot saturate the communication channel with requests, because it runs on a very low bandwidth connection, so each request should be correctly measured, where all operations on the machinery is being directed by states machines with dynamic priorities of execution, and the STL priority queue is doing a good job. But was a little bit complex to think in terms of source code with the model presented as state diagrams and flow control diagrams on a whiteboard, and took me about one week to finish the final skeleton of the primary source code.

As you know I am working on an Industrial Control System — ICS/DCS to be more specific — and this system requires a task schedule to activate some pumps with a very strict calendar, monitoring the amount of liquid that has been passed through the valve, and it should allow manual operations, interrupting the automatic operation of that node on the plant. This seems to be difficult to implement, as I wrote in past posts, we are using a priority queue that contains task requests, where every priority is entirely dynamic, and dependent on the state of the current state machine that is being executed according to the operation request.

Defining state machines is not so hard as it appears. Initially you can build constructs that can help on building automata processing much friendly than using plain code. Starting from the idea that you can place your state machine inside data structures allowing friendly editing without modifying the processing code. Any stateful processing can be migrated to state machines. As any automata can be represented in a state diagram and then it can be migrated to plain data structures. Even if you are using a purely functional programming language, you can place a stateful processing data structure to be processed as automata.

Graphical objects in ProView are providing two types animations and behavior attributes, where both can be highly customized. Dynamics are those animations related on how the object operates with the environment — mouse and keyboard — and the logical plant nodes. At the other side, actions are those XTT commands triggered with the user interaction. So, for example we have the Electric > ControlSwitch sub-graph, which has the action DigShift, but we can change the DigShift action to ToggleDig, allowing a digital input switching between True and False, and preserve the rotate animation which is inherited from its definition.