Programming for experts
P.
121 of 349
Validating scheme
Backgorund
Concept
For advanced programming using the validation scheme the following chapter includes the back ground.
The main task of an automation (control) system is to go through the user program so, that both event-oriented
message processing, such as the arrival of KNX telegrams, as well as cycle-oriented processing, such as timer, timer
switches etc. are processed. No need telegram may stuck in a queue for processing. In the Enertex ® EibPC always
all tasks shall be processed in same priority.
This demand is the first design criteria for the firmware:
•
Any statement in the application program must be treated as a process, processed within a cycle time.
Each statement is referred to the cycle-time processed in parallel.
As a consequence we can state:
•
In principle, the application program is processed cyclycally.
The program starts reading the "inputs" (messages) from timers, switches, etc, then it is processing the
user programm, then will switch the "outputs" and finally the whole thing starts over again. So this is
different to a "normal" program. That will be started only once and depending on the user inputs
subroutine calls occur and will be executed until the processing or other user initiates an other input.
Many KNX devices which can e.g. in addition to a touch panel operation mode, process simple logic, have a cycle
time starting from 100ms. For the pure KNX solution with perhaps 10 AND and OR combinations this will be enough
and due to the cycle time of 100ms performance problems might not occur. However, this logic is not very flexible or
powerful. The Enertex ® EibPC is not limited in this manner. In addition, it has the capability to work with TCP, UDP
and any RS232 telegrams and also to carry out extensive calculations. Therefore, a simple increase in cycle time is
not enough.
Finally:
•
The user shall have no problems with the cycle time and the programming shall be made as easy as
possible. A program shall be possible as follows
if Switch==ON then Write("Light-1/3/5“,ON) endif
We have already noted, that the program has to by processed cyclically. If the program is processed in
the style of a classic programming, initially it will be recognized in a cycle, the variable is in ON state and
the Light has to be switched ON by initiating a KNX telegram. In next cycle the same holds true and then
another telegram would be initiated. This is not intended, of course.
The tasks are
1.
Real time
The whole program shall be processed in one cycle
2.
Multithreading
Each statement shall be processed in one cycle
3.
Easy programming
The first steps when programming the user shall rapidly find solutions: „If a switch is pressed, send a
telegram to the actor“
From these requirements, the validation concept has its origins. Each variable, function or expression used knows
•
whether it has changed,
•
whether it has remained constant,
•
whether an event occurred,
•
whether dependent expressions are changing.
If a change has occurred in this sense, the object to the status "invalid" and initiates the evaluation of the object and
its dependencies again. If the object is then processed, it is valid. An "evaluation" of the function "write" for example,
is equivalent to writing on the bus.
The entire program is compiled in that way, so it will implement this dependency of the objects in an object table.
Variables
[EibPC]
x=2
y="SaunaDimmer-1/0/1"+3%+x
z='1/2/3'b01 or '1/2/4'b01
With this definition, variables are defined and initialized. After the first pass,
x
is set to 2 and
y
to the value of the
group address plus 3% plus
x
. In the next and all subsequent cycles changes
x
does not change any more, because
2 is constant. The things are different for
y
: If the group address is incoming and the transferred value has changed,
y
is re-calculated.
y
is dependent on an expression that has changed, and get this information "told".
y “
knows”
therefore, that it must be re-calculated. It was "invalidated" by the group address. Where
y
is only invalid, if the value
of the group address has actually changed. Similarly,
y
would recalculate when
x
would change. The invalidation of
the depending objects is made “bottom up" up to the level at which the altered dependencies no longer have the
effect of changes. If initially 1/2/3 is ON, the OR expression is ON and “tells” to
z
, if the OR was OFF before. Now if
1/2/4 is ON, the OR wlil be invalidated and shall be calculated again. Since OR is already ON,
z
is not invalidated,
and therefore need not be recalculated.
Optimum performance is therefore a priori guaranteed, since at the KNX bus max. 1 telegram will arrive each 40ms.
This telegramm certainly will not invalidate all objects, because only a certain -in a spophistacted program a
vanishing- part will depend on this message. Therefore the EibPC reaches a cycle time of micro seconds.
HandbuchEibPC_USA-30.odt, 2017-05-11
Enertex
®
Bayern GmbH - Erlachstraße 13 - 91301 Forchheim - [email protected]