So far only the client type side has been implemented. It means that the PROMOTIC application can estabilish the TCP connection with the opposite site, which acts as server.
The driver supports the usage of both PmaCommMsg and PmaCommGroup objects. For common data transfers, it is better to use the PmaCommGroup object.
For easy integration of this driver into the application it is handy to use: Preconfigurations in group "IEC8705 communication protocol"
| Baud rate | 4800 Bd (and higher) |
|---|---|
| Number of data bits | 8 (mandatory) |
| Parity | EVEN. The IEC 60870-5-101 standard specifically states that "EVEN" parity is to be used in order to meet data integrity "class I2". If you can change it here, then be aware that using another parity setting cannot guarantee the same data integrity level. |
| Number of stop bits | 1 (mandatory) |
| TCP/UDP port number | 2404 (according to IEC 60870-5-104 standard) |
|---|---|
| Ethernet transfer type | TCP (mandatory) |
| Number of repeats after unsuccessful Master transmission | 0 (mandatory) |
| Timeout of one packet transfer [ms] | 2000 (in this case it is only send message timeout, not receive message timeout.) |
| Filter ECHO chars | No |
| Not connect until first transfer | NOT checked (mandatory) |
| Close connection after every transfer | NOT checked (mandatory) |
| Response receipt timeout | The time (in milliseconds) the driver is waiting for the response on sending the message. If no response comes during this time, then the transfer of the message is terminated (the onEndOfTransfer event is triggered with error 24 or 66). |
|---|---|
| Type | Specifies the basic type of transmission defined in the IEC 60870-5 standard: 1=Balanced mode - The opposite side in this regime sends the data on change. 0=Unbalanced mode - This type has not been implemented yet. It is the Master-Slave communication where the opposite side (Slave) can send data as response on query. |
| Link address size of stations | The number of bytes (octets) for the Link address in protocol: 0/1/2 bytes |
| Link address of this station | The link address of the computer, running the PROMOTIC application |
| Link address of the second station | The link address of the station, the PROMOTIC application comunicates with: For "Balanced mode": Communication only with one station. The LinkAddr variable on the "Data-sent" tab of every Master message is not taken into consideration. For "Unbalanced mode": This configurator is not shown. The address is entered in the LinkAddr variable on the "Data-sent" tab of every Master message. |
| ASDU common address size | The number of bytes (octets) for the ASDU Common address data: 1/2 bytes |
|---|---|
| ASDU information object address size | The number of bytes (octets) for data object adress: 1/2/3 bytes |
| Size of "cause of transmission" value | The number of bytes (octets) for the "cause of transmission": 1/2 bytes |
| Commands termination type | The IEC command is usually transmitted in multiple communication messages ("cause of transmission" = 6=act, 7=actcon, 8=deact, 10=actterm ...). It is defined here, when the transmission command is considered as finished. 0 = wait for receive, if "cause of transmission"=10=actterm - The command transmission is finished after receiving the 10=actterm. 1 = do not wait for receive - The command transmission is finished after sending this command, there is no waiting for receiving the 10=actterm. |
The "PmaCommGroup > Parameters > Communication refresh rate [ms]" configurator is not defined for this driver and therefore is set to 0. The object does not send prompts for data transfers.
ItemId is the text identifier of the item that is used for addressing the value in the device. The "ItemID" configurator tells the driver how to receive or send the item value.
The text can be written manually, or it can be assembled in the window opened by the button to the right of the configurator.
Macro expression can be used for input (it is evaluated after starting the application).
The ItemId identifier may look like for example "CA1501.v6", where:
For the IEC 870-5-104 standard the connection check is done automatically by the driver and the designer can affect this only using the protocol parameter "t3 = Delay [ms] for connection testing (U-Frame TESTFR)".
| Send data type | It is possible to send all types of ASDU data/commands listed below, see List and description of supported ASDU. |
|---|---|
| Number of items | It is also possible to send multiple data of the same type simultaneously (some data types support this feature, it is not allowed for commands). |
| Send mode | This configurator is visible only if the protocol is IEC 870-5-101. For the IEC 870-5-104 protocol, the transmission is always done in the 0 = Sending non-requested data mode. 0 = Sending non-requested data - Standard "Master" data transmission without waiting for data request. 1 = Sending spontaneously requested data - Data transmission after data request for differential (spontaneous) data. The data is transmmitted with the transmission cause 3=spont without waiting for any confirmation. 2 = Sending data requested by general query - Data transmission after all data request. The data is transmmitted with the transmission cause 20=inrogen without waiting for any confirmation. |
Additional variables depend on the selected type and number of transmitted data., For example:
If there is no such message (or always ErrorFlag=2), then the opposite side receives no response and closes the connection.
The message receives the data sent from another station. The second station sends the values that has been changed. It is possible to receive all types of ASDU data/commands listed below, see List and description of supported ASDU.
There is a message parameter "Received data information type" in the object, that can be set to 0 or 1. This parameter specifies how the received data will be confirmed. For 0 (less general option) there will be FillLastIndex and FillLastAddr items generated on the "Data-received" tab, that will contain the index and address of the last received data. If multiple data items are going to be received, then it is better to choose option 1. For 1 there will be FillIndexes and Reserve items generated. The FillIndexes item is of the Array type and contains all indexes of all received data in the message. The Reserve item is not used, it always equals to 0.
If the information about the object adress 95 is received, then the value of the object is stored into the v95 variable, the time of the object is stored into the t95 variable, the qualifier of the object is stored into the q95 variable and the "cause of transmission" is stored into the c95 variable. The variables t95, q95 and c95 are not requested (only the value is received), but if present, then these must follow (in arbitrary order) right after the v95 variable.
The v95 variable can be followed by a variety of data filled in using the same principle.
See also: Preconfiguration "PmIEC8705 - Ethernet 104 - Communication set with data and panel"
The purpose of this command is more genaral but principialy the same as sending Master message of the "Data request" type. The "cause of transmission" can also be controled here.
If the PROMOTIC application needs to ask for the data from the opposite side (all, not only the changed values), then the PROMOTIC application must send Master message of the "Data request" type. This message will send ASDU-100 with "cause of transmission"=6=act and then wait for reply. The opposite side should send back the same message with "cause of transmission"=7=actcon.
Then the opposite side starts to send data messages (with "cause of transmission"=20=inrogen), that will be received into the variables defined in the PmaCommGroup object (or they can be accepted by Slave messages of the "Data receive" type).
After the termination the opposite side sends ASDU-100 message with "cause of transmission"=10=actterm - this message can be accepted by Slave message of the "Receive when nobody want" type.