Page 25
reply. However, if direct conversion is required message buffering will be
inevitable. If the received message data rate is higher than the transmitted data
rate, multiple message buffering (and eventual overflow) will occur. If the
received message data rate is lower than (or equal to) the transmitted data, only
one incoming message will have to be buffered while the previous message is
being transmitted.
The KITZ unit is capable of buffering up to 2048 bytes of message data (but not
exceeding 64 individual messages) on one channel while transmitting data on
the other channel. After this limit has been reached, received messages will be
ignored until space is available in the internal buffer (ie. a complete message has
been transmitted).
When multiple buffering of received messages occurs, the messages will be
converted and transmitted in the order in which they were received. The other
channel’s receiver will not be re-enabled until after all valid messages have been
converted and transmitted.
Section 8. KITZ ADDITIONAL FEATURES
8.1 Real time clock (RTC) synchronisation
The K-Bus protocol converter real time clock (RTC) can only be synchronised over
the IEC-870 communications link. A courier command allows setting of the RTC.
The command format is as follows:
Command Command IEC TIME Extended Milli- Minutes Hour Day Month Year
DTL Set IEC Length seconds.
Time DTL
(RTC) (EXT)
05 45 3C 07 0 - 59999 0 - 59 0 - 23 1 - 31 1 - 12 0 - 99
The protocol converter will check the incoming IEC-870 message for a
synchronise RTC (real time clock) command sequence and if found sets the RTC
to the specified time.
The ‘Synchronise RTC’ command must be the only command after the IEC control
byte within the message, otherwise normal protocol conversion occurs.
The RTC setting value sent by the master station should correspond to the start of
the transmitted message (to the KITZ unit).
If time-tagging of K-Bus messages is not required, the RTC need not be
synchronised.
To Next Page
Loading...