Showing results 1 to 2 of 2

Thread: Read IEC61850 Command AddCause after select write successful

  1. #1
    Join Date
    04.11.2015
    Posts
    4

    Default 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 1st or 2nd or 3rd ….. (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.

  2. #2
    Join Date
    01.07.2008
    Location
    Salzburg, AT
    Posts
    815

    Default Re: Read IEC61850 Command AddCause after select write successful

    Where is the mentioned attachment with Wireshark sniff?
    Forum is not the official Support of zenon, by cases demanding complexes analyzes i would recommend you to contact your local COPA-DATA Support.

    To your description i have following:
    - a 850-server can deliver the LastApplError (AddCause) in MMS InformationReport and only in negative case. And an InformationReport do not have InvokeID (only positive response - MMS Write response can have an InvokeID)
    - a positive response from server to client must have the same InvokeID as the client's request had. In MMS Write request and response the InvokeID must be the same, else the client cannot know on with command the response is coming.
    - have you tried to use in zenon the */AddCause variable together with */CommandRun and */CommandState? What these other variables are informing in negative case?
    - what is the control model? Enhanced security (with CommandTermination) or normal? Only in enhanced security there could be after positive Operate a negative Termination with an AddCause.
    Last edited by ursulak : 26th July 2017 at 10:14

Similar Threads

  1. Command Information IEC61850
    By anbkhn90 in forum zenon Energy Edition
    Replies: 2
    Last Post: 27th February 2017, 07:51
  2. Read/Write a single bit in a Byte/Word ?
    By EdgyUsername in forum zenon Supervisor
    Replies: 3
    Last Post: 14th September 2016, 17:10
  3. IEC61850 command origin
    By gemarcos in forum Drivers
    Replies: 5
    Last Post: 7th October 2014, 10:26
  4. Read and write variables from plc with VBA
    By cibertoni in forum VBA
    Replies: 1
    Last Post: 22nd September 2014, 16:36
  5. Replies: 2
    Last Post: 22nd September 2011, 01:32

Tags for this Thread

Posting Rules

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •