|
4.3.1 Protocol : IEC 62056-21 ( former IEC 61107 ) |
Telegram structure |
|
The protocol IEC 62056-21 offers five different protocol modes that can be used by tariff devices. These
are the modes A, B, C, D and E. In the modes A, B, C, and E data exchange takes place in both directions whereby the data are collected via
request. In mode D data are only transmitted in one directions in fact from the tariff device to the master. |
|
Information to the telegram structure see |
![]() |
|
With the channel button ( channel 1 ...12 ) on the bottom following settings are possible : |
|
Each character consists of one start bit ( binary = 0 ), 7 data bits, normally one even parity bit and one stop bit ( binary = 1 ) |
| Interface |
Any COM port can be allocated to each channel ( COM 1 up to COM 24 ). |
||||
| Modem |
An individual modem can be installed and connected for each channel. LIAN 98 is able to process up to twelve modems in the range of COM1 till COM24 simultaneously. Each modem, that is assigned to the selected channel is indicated. Normally this assignment will be recognized by LIAN 98 and the corresponding modem will be set. |
||||
| Setup modem |
The settings of the modem must be executed via the windows control panel "telephone and modem options". With this button you can check these modem settings and see if they concur with the LIAN 98 configuration. |
||||
| Connection type |
|
||||
| RTS Leading delay |
0 ... 1000 msec |
||||
| RTS Trailing delay |
0 ... 1000 msec |
| Baud rate |
Transmission speed : 25 - 115 200 baud ( variable, default 300 baud ) |
| Data byte |
7 Bit ( fixed ) for protocol mode A, B, C and D. |
| Stop bit |
1 bit ( variable ) |
| Parity |
even ( variable ) |
| Time out |
1 - 9999 msec ( variable ) : For 300 baud at least 600 msec. |
Settings in the channel window |
![]() |
| Protocol mode |
Mode A, Mode B, Mode C, Mode D and Mode E can be selected. |
| Counter address using OBIS code |
yes/ no |
|
In the following PDF file a typical meter reading with LIAN 98 is shown : |
|
|
![]() |
| Device address ( address of the target device ) |
The request message to be sent are provided with the device address of the SIM list during master simulation. |
| Response timeout |
1 - 30 000 msec |
| Number of frame retries |
0 - 255 |
| Baud rate change delay |
1 - 30 000 msec ( for 300 baud minimum 300 msec ) |
| Send request device ( TDBnum ) |
yes/ no |
| Send option select ( TDBnum ) |
yes/ no |
| Send password ( TDBnum ) |
yes/ no |
| Send break ( TDBnum ) |
yes/ no |
| Send A C K ( TDBnum ) |
yes/ no |
| Send N A C K ( TDBnum ) |
yes/ no |
|
|
![]() |
| Device address ( address of the source device ) |
The device address is only used in order to validate the request message during connection establishment. If the address in the SIM list does not correspond to the received address the RTU simulation will not be started. |
| Identification |
The identification message to be sent are provided with the identification of the SIM list during RTU simulation. |
| Response timeout |
1 - 30 000 msec |
| Number of frame retries |
0 - 255 |
| Send identification ( TDBnum ) |
yes/ no |
| Send password ( TDBnum ) |
yes/ no |
| Send break ( TDBnum ) |
yes/ no |
| Send A C K ( TDBnum ) |
yes/ no |
| Send N A C K ( TDBnum ) |
yes/ no |
| Send readout data ( TDBnum from/ till ) |
yes/ no |
| Send data messages ( TDBnum from/ till ) |
yes/ no |
| Baud rate change delay |
1 - 30 000 msec ( minimum 300 msec ) |
| Baud rate fallback time-out |
1 - 255 sec ( as per standard 60...120 sec ) |
|
LIAN 98 assigns internal an unambiguous type identificaton to each message type for protocol IEC62056 that also can be used for filtering. In the following list you will find the assigned values. Additional to the message type also the first 22 bytes ( byte 0 = start byte ) can be filtered in order to select e.g. messages by address. |
| TypeID | direction | description |
| 1 | con |
Request message ( Sign on ) |
| 2 | con |
Acknowledgement/ option select message |
| 3 | con | Command message : Password |
| 4 | con | Command message : Write |
| 5 | con | Command message : Read |
| 6 | con | Command message : Execute |
| 7 | con | Command message : Break ( Sign off ) |
| 129 | mon |
Identification message |
| 130 | mon |
Data message ( Readout ) |
| 131 | mon |
Data message ( programming mode ) |
| 132 | mon |
Data message ( programming mode ) using optional partial blocks. |
| 133 | mon | Error message ( programming mode ) |
| 259 | con, mon | A C K : Acknowledgement message positive. |
| 260 | con, mon |
N A C K : Acknowledgement message negative ( Repeat request ) |
|
Monitoring filters reduce capture on particular pre-defined data records. By setting the corresponding filters a carefully directed data preselection can be achieved, which results in a reduction of the data to be analyzed later. |
![]() |
Filter released |
yes / no |
||||||||||
Protocol specific |
Here you can define telegram-specific filters for monitoring in which several OR-linked triggers can be defined for one channel.
|
||||||||||
| add | Add the next OR-element. | ||||||||||
| remove | Remove the current OR-element. |
|
For the simulation and execution of data tests actions can be caused with the receipt of defined records. Therefore the possibility exists to define action filters, that effect the transmission of a send-sequence or transmit one or more message buffers ( TDB ). |
![]() |
| Filter released |
yes / no |
||||||||||
Protocol specific |
The action filter is described over telegram specific features corresponding to a filter setting. Additionally each action filter requires an allocation to a send buffer or alternatively to a send sequence.
|
||||||||||
| Sendbuffer number ( from, from/ till ) |
In correspondence with the action filter the message buffer "from" or the message buffers "from/ till" are to be sent. |
||||||||||
| Sequenceline number ( from, from/ till ) |
In correspondence with the action filter the send sequence is to be started at line number "from" or to be started at line number "from" and to be ended at line number "till". |
||||||||||
| add | Add the next OR-element. | ||||||||||
| remove | Remove the current OR-element. |
|
With the receipt of a telegram pre-defined as start trigger, recording is started. |
![]() |
Start trigger released |
yes / no |
||||||||||
Protocol specific filter mask |
Here you can define telegram-specific start triggers for monitoring in which several OR-linked triggers can be defined for the channel.
|
||||||||||
| add | Add the next OR-element. | ||||||||||
| remove | Remove the current OR-element. |
|
Monitoring can also be stopped by telegram-specific filters and/ or "stop on error" after a defined number of following records. The number of the following records is defined in the field "records after stop on error/ stop trigger" in the global parameters of the VFL settings. |
![]() |
Stop trigger released |
yes / no |
||||||||||
Protocol specific filter mask |
Here you can define telegram specific stop triggers for monitoring in which several OR-linked triggers can be defined for one channel.
|
||||||||||
| add | Add the next OR-element. | ||||||||||
| remove | Remove the current OR-element. |
|
Each alteration in the settings is displayed by an asterisk * in the caption title and will be only effective after saving. |
|
The sent and received messages of all channels are entered binary into the archive file. Before displaying on screen, the binary archived data are coverted to an easily readable procedure specific plaintext. The plaintext format is set separately for each channel. ( see "FMT file - Display format" ) |
![]() |
| Plaintext format 1 |
Everything is displayed |
![]() |
|
Additional to the plaintext output the transmission data can also be displayed in hexadecimal, decimal, ASCII, binary ( LSB first ) or binary ( MSB first ). Of course the plain text output can also be deactivated in order to display the transmission data only e.g. in ASCII format. |
![]() |
Error checks during receive |
| per character |
the start bit, the stop bit and the even parity bit. |
| per frame |
the start character, the frame checksum and the end character and the length. |
| *** TimeOut ! |
Within a telegram, there may be no pause between characters. In case of timeout
occurs it is assumed that it is the end of the telegram and the telegram check is started. The sensitivity can be parameterized in the
configuration ( timeout ). |
| *E: COM-PORT ! |
Error during writing on the COM port. May be it is already occupied by another program. |
| *E: Length ! |
The stop byte ( ETX, EOT ) is missing or set wrongly. |
| *F: Format ! |
Characters within a telegram that are expected on a fixed position are not on the right place. |
| *E: Checksum ! |
The checksum in the checksum byte ( BCC ) is incorrect. |
| *E: SYNC ! |
The receive routine initially searches for "/", SOH, STX, ACK oder NACK. |
| *E: Overflow ! |
Error message by UART. This error is noted only in the PRO file. |
| *E: Parity ! |
Error message by UART. This error is noted only in the PRO file. |
| *E: Start/ Stop ! |
Error message by UART. This error is noted only in the PRO file. |
Error checks during simulation |
| *E: Baudrate ! |
The baud rate character ( field Z ) in the message is wrong. |
|
When a meter device is using the "Object Identification System" ( OBIS ) for a clear identification of the meter values ( active power, reactive power, ... ) and this is parameterized in the channel window settings of LIAN 98, the OBIS numbers are supplemented with an explanation by LIAN 98. |
![]() |
|
Texts for the OBIS numbers are defined in the parameter list of the IEC 62056-21 protocol. A OBIS code consists of six value groups which are described with A... F and characterizes the data value. Texts for the value groups C, D and E are in the PAR list. The user of LIAN 98 can change already defined texts or supplement this list with further texts. ( also see <Identification of data sets> ) |
![]() |
|
Wuerzburger Ring 39, D 91056 Erlangen |
LIAN 98 Protocol Router, Simulator and Analyzer © Copyright 2001, 2006, 2011 by MAYOR GmbH. All Rights reserved. |