Step Position with IEC104

[djgaunt]

Hi

I'm trying to monitor the TAP (Step) position of a transformer. The IEC104 address from the RTU is of message type T32 - M_ST_TB_1, which is also available in the Zenon IEC 104 driver. This message is transmitted in two parts i.e. 8 bit unsigned (Step position) and then followed by a 32 bit unsigned (bit position) data type. Can you please explain if it is possible to interpret this type of message in Zenon 6.51, what Datatype do I use?

Regards


Dave

[ursulak]

According the IEC60870 Standard a message of Type Identification 32 - M_ST_TB_1 consists of:
- VTI - 1 byte with value with transient state indication = Transient bit <0..1> and 7 bits with Step position <-64..63> --> in zenon the whole VTI responds value of the variable <0..255> (USINT). Thus when transient bit is set or step position is negative one should decode the VTI, e.g. using small straton program or MATH driver. Else you can just create a USINT variable with type id T32 (or online import it from RTU).
- QDS - 1 byte with quality descriptor, e.g. Invalid, Overflow, Substituted bits --> in zenon responds status bits of the variable
- CP56Time2a - time stamp on 7 bytes --> in zenon responds time stamp of the variable value

In the ASDU T32 i do not see any "a 32 bit unsigned (bit position) data type"

[ursulak]

BTW, we call the driver iec870 (info just for search machines )

[djgaunt]

Thanks for the response. The problem appears to be the implementation of the IEC60870 driver in the RTU, which is sending two datagram's to the same IOA, the first part contains the (packed) position, which is correct as you have described above. The second datagram contains an extended position which uses the same IOA address, and is overwriting the first value received by Zenon.

This has been causing me some confusion, but I have now managed to use a workaround within the RTU.

Thanks again.

[ursulak]

The RTU's behavior you've described does not conform to the IEC60870 Standard. Thus, to manage it in the RTU is the only solution.

According the Standard each Information Object in monitor direction must have its own IOA. With other words: any data-point with type identification from range <1..40> must have an unique IOA. And must use ASDU (message) format defined in the Standard.

Also each command - in control direction - must have an unique IOA, but they can have the same IOA as data-points in monitor direction, e.g. a single command can have the same IOA as the responding single-point information, what IMHO is very comfortable.

[joelprasad]

The RTU's behavior you've described does not conform to the IEC60870 Standard. Thus, to manage it in the RTU is the only solution.



According the Standard each Information Object in monitor direction must have its own IOA. With other words: any data-point with type identification from range <1..40> must have an unique IOA. And must use ASDU (message) format defined in the Standard.



Also each command - in control direction - must have an unique IOA, but they can have the same IOA as data-points in monitor direction, e.g. a single command can have the same IOA as the responding single-point information, what IMHO is very comfortable.

Hello,

I am trying to change the step positions from the SCADA. I am using command processing with pulse signal. The positive pulse should increase the step position by 1 and vice versa. However it is not happening. 
Is there any suggestions with regard to this?
Note: We are able to do the same from other software's.

[ursulak]

hello joelprasad
you gave too less information. 

In general: the iec870 driver, for C_RC_NA_1 (T47), is not using "DPI/DPC mapping", so the value for "lower" is 1, the value for "higher" is 2 (according definition in IEC60870-5-101). 
If in the PLC this shall be a pulse, then it makes things complicated, as the action type 'pulse-commands' works only on values: 0-off, 1- on. Would be possible to reconfigure the slave to expect latch, not pulse, for regulating step commands?