Basics¶

Welcome to the basics tutorial for MTPPy. This section introduces data assemblies and services. You will learn how to retrieve, access and update the attributes of a data assembly by means of the python APIs supported by MTTPy2.0

Data Assemblies¶

Objects of class DataAssembly serve as the base interfaces to automation building blocks. They define the contract between POL and PEA and provide a standardized way to access and manipulate the data elements of automation building blocks. For details about information flow between POL, the OPC UA server, and the PEA, see Architecture.

Step 1: Get a handle to the Data Assembly¶

A DataAssembly allocated by a Service's Procedure can be retrieved from the procedure collection. Use Service.get_base_interface(<tag_name>) to retrieve procedure parameters, process values, report values, and other required equipment:

data_assembly = myService.get_base_interface("T100")

Step 2: Set and get values¶

There are three supported ways to get and set an attribute of a DataAssembly or a ParameterElement. Common value attributes include V, PV, and VOp, depending on the type.

Note: All the attributes are case-sensitive

Pythonic Dict style¶

The elements of a DataAssembly or a ParameterElement are exposed as dictionary keys. Use the attribute name defined by PNO MTP 2.0 to read or write the value:

da["V"] = 42
x = da["V"]

da[da.V_] = 42
x = da[da.V_]

Pythonic Attribute style¶

The elements of a DataAssembly or ParameterElement are also exposed as class attributes:

da.V = 42
x = da.V

Setter/Getter style¶

The DataItem elements of a DataAssembly or ParameterElement are also exposed through getter/setter methods. Retrieve an item with get_item(key), then use set_value() and get_value():

da.get_item("V").set_value(42)
x = da.get_item("V").get_value()

Services¶

In the MTP framework, a Service represents the core logic of an automation application. Services coordinate components, manage execution flow, interact with DataAssembly objects, and typically contain one or more Procedures that define operational sequences.

State Machine¶

Each Service owns a state machine. The current state is exposed through ServiceControl.StateCur; the enabled commands are exposed through ServiceControl.CommandEn. A command is accepted only when the service is active, the selected operation/source mode allows the command channel, and the command is enabled for the current state.

States¶

The state machine has two kinds of states:

Commands¶

The available commands are start, stop, hold, unhold, pause, resume, abort, restart, complete, and reset. The command changes the state as follows:

Command enablement is state-dependent. For example, start is enabled in idle, pause and restart are enabled in execute, resume is enabled in paused, unhold is enabled in held, and reset is enabled in completed or aborted. stop and abort remain available in the applicable active states so that a running operation can be brought to a controlled stop or abort.

stateDiagram-v2
  direction LR
  [*] --> idle : off/op
  idle --> starting : start
  resetting --> idle
  state "abortable states" as stop_path {
    state "stoppable states" as hold_path {
      starting --> execute
      state "holdable states" as normal {
        execute --> pausing : pause
        pausing --> paused
        paused --> resuming : resume
        resuming --> execute
        execute --> completing : complete
        unholding --> execute
      }
      normal --> holding : hold
      holding --> held
      held --> unholding : unhold
    }
    hold_path --> stopping : stop
    stopping --> stopped
  }
  stop_path --> aborting : abort
  aborting --> aborted
  completing --> completed
  completed --> resetting : reset
  stopped --> resetting : reset
  aborted --> resetting : reset
  classDef transient fill:#fff3cd,stroke:#b7791f,stroke-width:2px
  classDef nontransient fill:#e6f4ea,stroke:#2f855a,stroke-width:2px
  classDef nontransient_code fill:#7dc98f,stroke:#1e5a38,stroke-width:4px
  classDef control fill:#e8eef7,stroke:#405a7d,stroke-width:2px
  class starting,holding,unholding,completing,stopping,aborting transient
  class pausing,resuming,resetting transient
  class idle,held,paused,completed,stopped,aborted nontransient
  class execute nontransient_code
  class normal,stop_path,hold_path control
  note right of stop_path
    stop enters stopping,
    then ends in stopped
  end note
  note right of aborting
    abort enters aborting,
    then ends in aborted
  end note

Green states are non-transient and execute cyclic application logic. Yellow states are transient and complete after one entry/run/exit cycle. The blue composite states are nested — holdable inside stoppable inside abortable — so each adds one command (hold, then stop, then abort) to the states it encloses; reset returns the terminal states to idle through resetting.

The diagram shows the service's operating states, so it omits undefined (the inactive service) and the restart command, both of which behave like start. The nested blue composites group the states that share a command: the innermost holdable states are where hold is available, the enclosing stoppable states add stop, and the outermost abortable states add abort — so a transition drawn out of a composite is available from any of its inner states.