Language Overview

Steps and Transitions

The graphical language of JGrafchart is based on Grafcet/Sequential Function Charts (SFC). The language is state-transition oriented. A JGrafchart program consists of a function chart that represents an activity flow. By convention the flow goes from the top of page to the bottom of page. More formally a Grafcet function chart is a bipartite directed graph consisting of steps and transitions.



A step can be inactive or active. An active step is indicated by a filled token. Initial steps are special steps that are automatically activated when execution starts. Initial steps are shown graphically by a double rectangle. Associated with the steps are actions. The actions are expressed in a textual action language. The actions are performed when the step is activated, deactivated, aborted, or periodically, while the step is active. The transitions have an associated boolean condition that acts as a guard. In order for a transition to be enabled, all the steps immediately preceding the transition must be active. A transition that is enabled fires if its condition is true.

Parallel and Alternative Paths

In JGrafchart it is possible to express parallel and alternative paths as shown below.


Macro Steps

Macro steps are steps that contain an internal function chart. The internal function chart is located on the subworkspace of the macro step. When the macro step is activated the enter step of the internal function chart is activated. When the execution in the internal function chart has reached the exit step, the transition after the macro step is enabled. An exception transition is a special type of transition that only may be connected to a macro step. The exception transition if connected to the exception port on the left-hand side of the macro step. An ordinary transition connected to a macro step does not become enabled until the execution of the macro step has reached the exit step. An exception transition, however, is enabled all the time while the macro step is active. When the transition is fired the execution inside the macro step is terminated and the step succeeding the exception transition becomes activated. Exception transitions have priority over ordinary transitions in cases where both are fireable. Macro steps have history. When an exception transition aborts the execution of a macro step, the execution state is saved. The macro step can be resumed in this saved state if a transition connected to the special history port of the macro step is fired. The history-input port is located on the right hand side of the macro step.




Macro steps may have multiple inputs and multiple outputs. In this case the enter and exit steps are also multiplied. Macro steps with multiple inputs and/or outputs resemble the hierarchical states (superstates) in Statecharts. They are useful for implementing hierarchical state machines.

Procedures

Step-transition sequences that are used in several different contexts can be represented as procedures. A procedure has a procedure body stored on the subworkspace of the procedure. The body begins with an enter step and ends with an exit step in the same way as for macro steps. Procedures are reentrant and my be recursive. Procedures may have parameters. All internal variables within the procedure can be used as parameters. Parameters can be assigned values both using call-by-value and call-by-reference. A procedure can be called in three different ways:

  • Directly from the procedure object.
  • Through a procedure step.
  • Through a process step.
  • Through an action within a step or a button.

When a procedure is called from a procedure step, the transition(s) after the procedure step does not become enabled until the execution has reached the exit step of the procedure. Hence, this corresponds to an ordinary procedure call, When a procedure is called from a process step the transition(s) after the procedure step is enabled immediately. Conceptually, the procedure call is spawned and executed in a separate execution thread. This is, however, not the way it is implemented. The same thing happens when the procedure is called (started) from an action.


Workspace Objects

Workspace objects are objects that contain a subworkspace. The subworkspace may contain arbitrary language elements. Workspace objects can be used for three main purposes:

  • As a way of structuring large applications.
  • As a compound variable comparable to a C struct,
  • As a way of representing objects that have attributes and methods

When a workspace object is used as a structuring element it is possible to programmatically enable and disable it. It is also possible to have a workspace object being executed at a longer scan-cycle than the rest of the application. The icon of a workspace object can be defined by the user.


Types and Variables

JGrafchart supports four basic types: boolean, integer, real, and string. For each basic type there is a corresponding variable. The variables are either input variables: internal variables, or output variables.

  • Input variables receive their values from the external environment. They can be connected to I/O cards, input sockets, etc. Input variables can be read from but not written to from the JGrafchart application.
  • Internal variables receive their values from the JGrafchart application. Internal variables can both be read from and written to, unless they have been specified as constant, in which case they only can be read from.
  • Output variables receive their values from the JGrafchart application and transmit these values to the external environment. They can be connected to I/O cards, output sockets, etc. Output variables are normally only written to. However, it is possible to also read from them, in which case the last written value is returned.

Some examples of different types of variables are shown below:


JGrafchart Action Language

JGrafchart contains both graphical and textual language elements. The textual format is primarily used for expressing step actions and transition conditions. Step actions can be associated with steps (ordinary steps, initial steps, enter steps, exit steps), macro steps, procedure steps, and buttons. A step action consists of two parts: an action qualifier and the actual action. The action qualifier decides when the action should be executed. Five different types are available.

  • Enter action
  • (Stored action). An enter action is executed once when a step becomes active or when a button is pressed. The syntax for enter actions is
S "action";
  • Exit action.
  • An exit action is executed once immediately before the step is deactivated, The syntax for exit actions is
X "action";
  • Periodic action.
  • A periodic action is executed periodically while a step is active. The period is given by the scan-cycle at which the step is executing, The syntax for periodic actions is
P "action";
  • Abort action
  • An abort action is executed once when a step is aborted due to the firing of an exception transition. The syntax for an abort action is
A "action";
  • Normal action
  • (Level action). A normal action is used to associate the truth-value of a boolean variable with the activation status of the corresponding step. The boolean variable becomes true when the step become active and becomes false when the step becomes deactivated. If the step becomes deactivated and activated in the same scan-cycle the boolean variable remains true. In order to work properly normal actions may only refer to boolean variables that reside within the same execution context as that of the step or button containing the normal action. For example, the boolean variable may not reside in another top-level workspace. The syntax for a normal action is
N "boolean variable";
The "action" in the syntax definitions above can be of two different types:
  • Assignment
  • In this case the syntax is
"variable expression" = "expression"
The "variable expression" is either a direct variable reference or an expression that evaluates to a variable reference, The way the "expression" is evaluated is determined by the type of the variable. For example, if the variable is a real variable the expression will be evaluated as a real-valued expression. JGrafchart uses automatic type casting.
  • Method call.
  • In this case the syntax is
"object expression"."methodname"(arg1,...argn)
Method calls are used to call a built-in method of an object. Methods are available for changing size, position, etc of objects, showing and hiding workspaces, enabling and disabling workspaces, doing printouts, etc. In many cases the methods are implemented by calls to underlying Java methods.

The action language is also used to express transition conditions. A transition condition is represented by an expression, which is evaluated as a boolean expression.

Function chart creation

Dragging and dropping language elements from the palette to the left in the editor window into a workspace and connecting them together creates function charts. Clicking and dragging the connection stubs at the ports of the different language elements creates connections. The connection creation is syntax-driven. It is not possible to create any illegal connections, for example connecting a step directly to another step.

Execution model and scoping rules

JGrafchart uses the traditional PLC execution model. A separate periodic thread executes each top-level workspace. Every period (scan-cycle) the thread performs three operations:

  1. Read inputs
  2. Execute one scan of the application. Outputs of enter, exit, periodic, and abort actions are written.
  3. Write outputs of normal actions

The execution of the application is performed in two steps. In the first step every transition is evaluated, If the preceding steps of the transition are active and the transition condition is true then the transition is fired. Firing the transition involves setting the activation status of the preceding steps for the next scan to false and setting the activation status of the succeeding steps for the next scan to be true. In the second step the activation status of the step is updated. This evaluation strategy eliminates the risk for chains of transition firings within the same scan-cycle. The strategy also effects how alternative transitions with non-mutually exclusive conditions are handled. In JGrafchart all of these alternative transitions will be fired, as shown below. This conforms to the Grafcet standard. It is also gives a fully deterministic behavior. It is good programming practice to make sure that alternative transitions always are mutually exclusive.



Before a function chart can be executed it must be compiled. During compilation the following operations are performed:
  • For every transition, references are set up between the transition and its preceding steps and between the transition and its succeeding steps.
  • For every step, the step actions are parsed and an abstract syntax tree is created.
  • For every transition, the transition condition is parsed and an abstract syntax tree is created.
  • The abstract syntax trees are traversed and a symbol lookup is performed where references are created between the variable nodes and the objects, e.g., variables that they refer to,

JGrafchart uses lexical name scoping. A variable or object reference can be either global or local. A global reference starts with a top-level workspace name and then uses dot-notation to access lower lexical layers. For example, the reference

W1.M1.V1

could refer to a variable named V1 contained in the macro step M1 that in turn is found in the top-level workspace W1. A local reference is local to the lexical context in which the reference is declared. For example, a reference to V1 from a step action of a step located at the same workspace as V1 is simply written as "V1". During symbol lookup the search begins at the lexical context of the expression. If a matching object is found, the lookup is completed, If not, the search continues at the next higher lexical level, in this example the top-level workspace W1. The effect of this is that names on a lower lexical level hide the same names on higher lexical levels, in the same way as in ordinary lexically scoped programming languages. It is also possible to use dot-notation to reference the internal parts of object groups.


The symbol lookup is currently not always type-sensitive. For example, when looking up the reference for a variable node named "S1", a reference is created to the first object with the name "S1", irrespectively of if the type of the object matches the context in which the variable node occurs. For example, assume that "S1" is the name of a step. The transition condition "S1 > 100" would not generate any compilation errors. This behavior is something that is subject to change in future releases.

Compilation errors and warnings are shown in the pull-down menu in the toolbar at the top of the editor window, If the compilation was successful the function chart can be executed. During execution it is not possible to drag and drop elements from the palette or to add elements from or to the clipboard. It is also impossible to delete language elements.