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.
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.
|
Logic input signal |
|
TRUE
|
?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.
The attributes of the
object bodies have, where appropriate, been divided in groups:
and the following format is
used to describe each attribute:
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.
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.
Description
|
||
pwr_tObjid...:
Objid |
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
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.
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.
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.
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
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.
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.
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.
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.
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 .
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 .