Introduction

Classes

An object class represents a well-defined function or method. It is characterised in one way in the development environment, for example by a symbol and certain attributes, and in another way in the target environment. From a general point of view a class contains data and code. Executable code exists only in the target environment.

The data of the class is divided into head and body. The object head, which has the same appearance in all object classes, is described in PROVIEW/R Designer's Guide . The attributes of an object class, which are used to describe the current state of a single object, are located in the body. It is not quite sure that the whole body always is stored in rtdb.
The description of an object starts with the name of the object class and a short description of the function of the class. After that the graphic appearance of the class follows as well as the attributes of the object body.

Graphic Appearance

If an object class has a graphic representation, the description starts with its symbol as it looks like when all in- and outputs are shown. In- and outputs are shown only if they are marked "Used" in the Attribute Editor. If the user wants to hide not used in-/outputs in the symbol of an individual object, it is done by toggling the Used-flags by means of the Attribute Editor. Inputs left open result in warnings at compilation, otherwise there is no difference in function compared to inputs marked Unused.

Object classes with graphic representation have the common appearance:

The name of the object class appears from the head of the object symbol. Inputs are on the left hand of the symbol; outputs on the right. In- and outputs designed for logical quantities are denoted by lower-case letters and analog (=continuous) signals by capital letters. Table 1-1 specifies how logical signals is interpreted.

Logical Signal Values

 

Logic input signal

Logic output signal

TRUE

?0

1

FALSE

0

0

To the inputs there are signals of corresponding types connected. Analog signals to analog inputs and logical signals to logical inputs.

When an object attribute has to be assigned a constant value (? 0), which does not exist as an independent signal, the use of an Av or Dv object, connected to the input by a GetAv or GetDv object, is recommended. This value can then be handled by means of the GetAv respectively GetDv object's object display.

If the input signal is connected to an input, the value of the signal, in the normal case, is stored in the object. But there are a number of exceptions of this rule when the value of the signal is used without any previous storage.This is the case in e.g. And , Or , Xor , Timer , Wait , Waith , Pulse , SR flip flops, ASup, DSup object class. That is the reason why some object classes can not use inputs left open. If an input of this type is left open, the result would be warning indications in both the SYNTAX-control and the COMPILE-operation in the PLC edit session.

The principle in reading the value of an input signal, whose value is not stored in rtdb (the real-time database), is to read the corresponding output of the connection -- not the input itself. The flags, InRtdb respectively NoRtdb, show if an input signal is stored in rtdb or not.

Not connected inputs receive a default value according to the type object of the class. This default value is specified in most attributes and can be changed for some attributes by means of the Attribute Editor in the development environment and for others in the target environment.

The last segment name of the object appears at the bottom of most object symbols; the default ends with a figure.

Attributes

The attributes of the object bodies have, where appropriate, been divided in groups:

·   input attributes

·   output attributes

·   internal attributes

and the following format is used to describe each attribute:

attribute name

Graph name:
Type: attribute data type
Flags: attribute flags
Default value:

Inputs respectively outputs in objects with graphic symbols, have names specified by Graph name .

The Type entry specifies the data type of the attribute.

The Flags entry specifies, in which environment and situation the attribute is valid.

Default value entry is used to show the default value of an attribute.

Type Entry

The type entry indicates the expected data type of the data specified of the attribute. The attribute itself does not have any data type.

Table 1-1 lists traditional standard data types.

Note! Attributes of the type pwr_tFloat32 are precise to 7 digits. It is worth to remember this, especially in the use of objects as Timint, Sum etc. where the output can be very large numbers.

Data Types

Data Type

Type

Description

void

 

 

Byte signed

pwr_tChar

pwr_tInt8

pwr_tString8

pwr_tString16

pwr_tString40

pwr_tString80

pwr_tString132

pwr_tText[ ]

 

 

Contains up to 7 characters.

Contains up to 15 characters.

Contains up to 39 characters.

Contains up to 79 characters.

Contains up to 131 characters.

Contains up to 1023 characters.

Byte unsigned

pwr_tUInt8

 

Longword integer (signed)

pwr_tInt32

Integer, e.g. ErrorSoftLimit = 10

Longword (unsigned)

pwr_tUInt32

pwr_tBoolean

pwr_tVid

pwr_tOix

 

Boolean type, true or false

Volume identifier

Object index

Word integer (signed)

pwr_tInt16

 

Word (unsigned)

pwr_tUInt16

 

 

pwr_tTime

Type of time in internal format.

Float

pwr_tFloat32

This value are precise to 7 decimal digits.

Double

pwr_tFloat64

This value are precise to 16 decimal digits.

pwr_tVid: vid
pwr_tOix: oix

pwr_tObjid

Object identity

pwr_tObjid...: Objid
pwr_tUInt32: Offset
pwr_tUInt32: Size
pwr_tUInt32: Flags

pwr_sAttrRef

Attribute reference

Flag Entry

Input Attribute Flags

Input Flags

Description

DevOnly

The attribute exists only in the develop environment

InRtdb

The value of the connected signal is stored in rtdb.

NoInvert

The value of a digital input can not be inverted.
Normally the value of digital inputs can be inverted.

NoRtdb

The value of the connected signal is used without any previous storage in rtdb. If the input value will be read it has to be done from the output of the connected object.

OpenCompileFixParam

The value of the attribute is used when the input is left open. This value is set in the develop environment by means of the Attribute Editor and is read at the compilation.

If the value is changed later at the execution, for example by means of a function in C- or PLC program, no attention is paid to the changes. So there is no sense in changing the value in rtdb of this attribute.

OpenExtern

If the input is left open the value of specified output in the same object is used.

OpenNoFunction

No attention is paid to an input left open.

OpenParam

The value of the attribute is used when the input is left open. This value is in the develop environment set by means of the Attribute Editor, and changes in the target environment, for example by means of an object display or a process graphic, is considered.

 

The attribute looks like a design parameter, i.e. as Param in table . Consequently an Access-flag can be added to the attribute.

Attribute flags whose name begins with Open concern inputs left open.
An arbitrary input in some object xxx in the
PLC Editor is either connected or left open.

This case can be handled in two quite different ways by the runtime system.

·   The pointer is located in rtdb. An unconnected input points to a value also located in rtdb. Changed value is concerned.

When the input is connected the value is pointed to used. This type of input is flagged OpenParam.

·   If the pointer is not placed in rtdb but in the exe-module the input is flagged OpenCompileFixParam.

Output and Internal Attribute Flags

Flags

Description

Access

This flag is combined with a parameter and means that changes of the attribute is subordinated to some restrictions. Before a change is accomplished, for example from an object display or more info form, the authorisation of the operator is checked and where appropriate, the proposed value against limit values. This concerns for example Gain in the Pid object whose access parameters are AccGain, MinGain and MaxGain; i.e. access parameters are named as the parameter itself, preceded by the prefix Acc.

CompileFixParam

The value of the parameter is read at the compilation, and must not be changed in rtdb.

CompileSetParam

The value of the parameter is set by some job during its initialisation, for example ScanTime in the Pid object.
The parameter is intended for reading, and will not be changed in run time.

DevOnly

The attribute exists only in the develop environment.

FixParam

The value of the parameter is read by the actual job during its initialisation in the run time system. If the value then is changed in rtdb the new value will not be used until next time the job is restarted.

InitSetParam

The value of the parameter is set by the PLC program during its initialisation, for example ValueIndex in an Av object.
The parameter is intended for reading, and will not be changed in run time.

Intern

The parameter, which is used internal by the object, is updated by the PROVIEW/R system or the development environment.

Operator

Signal order is set by the operator, and is reset by the PROVIEW/R system when it has been noticed.

OutNoVal

The output of the signal is not stored in rtdb. (Concern Getxx objects)

Output

The output is set by the PROVIEW/R system and stored in rtdb.

Param

Design parameter. It is set by means of the Attribute Editor. Changes in the target environment is taken into consideration.

PwrConstant

The value of the attribute is determined by the PROVIEW/R distribution and must not be changed.

RunTimeOnly

The attribute is used only in the runtime environment

Output signals reflect the state of the object. They are handled as parameters apart from the fact that they are available from the Graphical PLC Editor.

Default Entry

The attribute receives as standard a value according to the type object of the class, if nothing else is stated. If there is a relevant value, it is specified at this entry.

 

 

Glossary

Tick

The nominal scanning interval, in seconds, of the PLC subprocess with the shortest ScanTime in the node, is one tick. This means one tick is equal to 0.02 seconds or an integer multiple of 20 milliseconds.

Timer Control

Some objects make use of so-called timer control. After a certain time, specified by the object's TimerTime , a reaction takes place, e.g.

·   a signal managed by timer control are set or reset

·   a message is sent

The time TimerTime , is counted from a specific event, e.g. a leading edge on some of the object's inputs.

Timer control always runs together with the PLC subprocess with the shortest ScanTime . This means improved performance to such objects that are part of PlcPgm objects, which do not execute each tick. On the other hand, if the current object is included in a PlcPgm , which execute each tick, the timer control makes no advantages.

To Change an Active Timer

If an active timer is to be changed this is done by changing the value of the object's TimerCount in the following way:

·   to increase the running time with 600 seconds e.g., TimerCount is to be increased with the value 600 seconds / 1 tick.

·   by setting TimerCount = 0 or TimerFlag to FALSE a timer control in progress is aborted.

Local Objects

If a certain node is considered, objects which only belongs to that node may be denoted as local objects. From the view of that node other objects are denoted none-local objects.

Reading of an attribute in a none-local object is done by means of a subscription. A local copy of the object is created and this one is updated periodically. The reading is done in the local copy.

It is only possible to update attributes in local objects. If an attribute in a none-local object is to be updated this has to be carried out in the current node.

Local respective Remote Signals

Each process node handles a certain number of physical signals. This are either connected to some card on the buss of the node (local I/O system) so called local signals or to cards in distributed I/O system(s) ( remote I/O systems ) so called remote signals.

The IO job (see IOHandler ) handles among others, data exchange with the distributed I/O-systems as serial communication. Remote signals by the type:

·   Ai are handled by the period: ScanInterval CycleTimeSerial

·   Ao, Di, Do, and Co are handled by the period: CycleTimeSerial

The signal conversions, for both local and remote signals, are done in the process node.

Comments to Some Attributes

Timer

The time specified by TimerTime in such objects as Pulse , Timer , Posit , Wait , Waith , ASup is converted and stored, in the unit of tick, as a 32 bits integer in the attribute TimerCount . This is done every time when a new time shall be set. The longest time put in figures is then 2 147 483 647 ticks, which makes a maximum of 42 949 672 seconds or about 497 days.

"Fast" running PLC programs

Assume a PLC program containing an object with the attribute TimerTime and which execution period is 20 milliseconds. As TimerTime / 0.02 is truncated to the nearest lower integer, TimerCount is assigned the value 1, both if TimerTime = 0.025 or 0.035 seconds, i.e. the TimerTime ought to be specified as a time equal to an integer number of ticks .

"Slow" running PLC programs

Assume that a PLC program with ScanTime = 1 second containing a Pulse object with TimerTime equal to 2 seconds.

If the delay d1 is greater than d2, the 100 ticks delay does not elapse at the 3rd execution. This means that the effective delay is about 3 seconds and the nominal delay is 2 seconds, because the output of the Pulse object is not cleared until the 4th execution.

The effective time can, according to the current CPU-load, be longer or shorter than the time specified by TimerTime .