Read IEC61850 Command AddCause after select write successful
I am currently facing an issue with the IEC61850 SBO command AddCause.
I read the command fail AddCause by using this command info variable: */Oper.AddCause
The variable works fine if the failed condition already exist before select.
However, if the failed condition is after select and operate command write successful, Zenon will not get the command AddCause even though server replied with the AddCause information report.
Then, the command failed AddCause is read on the next 1[SUP]st[/SUP] or 2[SUP]nd[/SUP] or 3[SUP]rd[/SUP] ….. (Randomly) command process even though the command is executed successfully without error.
This situation often happen when synchrocheck fail condition where synchrocheck process is only start when operate is write successful.
Referring to the attached Wireshark file for synchrocheck failed condition:
Client: 10.6.99.223 | Server: 10.6.201.1
1.Synchrocheck Condition = Failed
2. Client write select command (Invoke ID = 81)
3. Server replied write successful (Invoke ID = 81)
4. Client write operate command (Invoke ID = 83)
5. Server replied write successful (Invoke ID = 83)
6. Synchrocheck start in server device-->Server replied: AddCause “Blocked by Synchrocheck”(Invoke ID = 2685612049) --> This is not read in Zenon
7.Synchrocheck Condition = OK
8. New select and operate command write successful (Invoke ID = 97 - 99)
9. Server replied command successful (Invoke ID = 2687184937)
10. New select and operate command write successful (Invoke ID = 109 - 111)
11. Server replied command successful (Invoke ID = 2687184937) -->AddCause is read “Blocked by Synchrocheck”
In this condition, Zenon unable to read the AddCause correctly when synchrocheck failed.
But, the addcause is read after that during command successful (This happen randomly).
I repeated step 1 to 6 with IED Scout as client and I get a positive result where the AddCause is show immediately after reply from server.
Referring to the attached Wireshark file for interlock failed condition:
Client: 10.6.99.223 | Server: 10.6.201.1
I did another test where the interlock condition is failed after select write successful, and I am able to duplicate the result as in synchrocheck.
1. Interlock condition = OK
2. Client write select command (Invoke ID = 41)
3. Server replied write successful (Invoke ID = 41)
4. Interlock condition = Failed
5. Client write operate command (Invoke ID = 43)
6. Server replied write successful (Invoke ID = 43)
7. Server replied: Blocked by Interlock --> (Invoke ID = 2685612049) --> This is not read in Zenon
8.Interlock Condition = OK
9. New select and operate command write successful (Invoke ID = 57 - 59)
10. Server replied command successful (Invoke ID = 2687184937)
11. New select and operate command write successful (Invoke ID = 73 - 75)
12. Server replied command successful (Invoke ID = 2687184937)
13. New select and operate command write successful (Invoke ID = 89 - 91)
14. Server replied command successful (Invoke ID = 2687184937)
15. New select and operate command write successful (Invoke ID = 105 - 107)
16. Server replied command successful (Invoke ID = 2687184937) --> AddCause is read “Blocked by Interlock”
Again, I repeated step 1 to 7 with IED Scout as client and I get a positive result.
This is a migrated post! Originally posted on 26.07.2017 by user ckkeong. Please be aware that information can be outdated.
Disclaimer
This document governs the use of our Community Forum. By registering and using the platform, you accept these conditions.
The COPA-DATA Community Forum serves to encourage the exchange of information and experience about the zenon software between forum users respectively zenon users.
Please mind that any published information on the Community Forum is the subjective opinion and view based on the experience and the level of knowledge of the author. COPA-DATA does not overtake any responsibility for the content and the accuracy of the shared information.
Users of the Community Forum are encouraged to share only well-founded experiences and to point out any risks associated with the implementation of proposed solutions to problems. COPA-DATA at its absolute discretion, reserves the right to moderate the forum. In this connection COPA-DATA may remove any information containing false facts, potentially dangerous solutions, bad language or content that may insult, degrade or discriminate others. COPA-DATA may block a non-complying user from forum access if the user violated this provision.
COPA-DATA reserves the right to change this document from time to time at own discretion.
Ing. Punzenberger COPA-DATA GmbH
Karolingerstraße 7b · 5020 Salzburg · Austria
www.copadata.com