Showing results 1 to 5 of 5

Thread: Control from many sides to Substation

  1. #1

    Default Control from many sides to Substation

    Hi all,

    In substation, normally, the switch-gears ( Circuit Breaker, Disconnecting Switch ...) are controlled:

    - From local substation.
    - From Local Dispatching Center.
    - From National Dispatching Center...

    Therefore, these devices need to be controlled from exactly the status of command authorization switch. If this switch is Local mode, just only local substation can control the controllable devices and the others cannot and vice-visa, if this switch is LDC (Local Dispatching Center) just only LDC can control and the other cannot..

    I just did the solution for this problem was using an internal variable to decentralize the command authorization and integrate in each interlocking of command processing for each devices. But, when the substation grows larger, added more devices, this solution was not good. It took me a long time to do and some time will be out of control.

    Can you help me out with more effective solution for this case?

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

    Default Re: Control from many sides to Substation

    >I just did the solution for this problem was using an internal variable to decentralize the command authorization and integrate in each interlocking of command processing for each devices.
    Your use-case is absolutely normal (in general, maybe not in detail, each system is a little bit different), the solution - basing on interlocking conditions basing on general internal variables - the recommended one .
    But unfortunately - as you have written - the workload to implement the solution increases with each new command group . This is a "price" for open possibilities of the system characteristics like e.g. emergency controls, special routines for only parts of the system, etc.
    We know from zenon users the 2 kind of wishes: to have possibility to implement in zenon a project covering any use-case and - to have simplest-possible, fast configuration and pre-defined routines - to lower efforts in project enhancements. Unfortunately these 2 wishes are contradictory and we are still looking for ideas for features lowing these efforts. If you have some idea what exactly will support your use-case - please do not hesitate to share it.

    Hints:
    • keep the quantity of Command Groups as low as possible. Use command groups basing on substituted references - to response, command and interlocking variables, e.g.: response: *_RV; command: *_CO: interlocking: *_OpnEna, *_ClsEna, etc. Than you will be able to use single command group for switches represented in different devices.
    • before creating commands - plan the substitution and rename process variables. It is much easier to use well substituted groups when zenon variables have suitable names. Please note that when the iec850 driver communicates on 'Symbolic Address' then variables of all devices can be renamed to follow syntax suitable for substitution; and the variables of offset-basing drivers like iec870, dnp3 etc. could be renamed too.
    • if the reason to use many command groups are many command screens - because you want to display different additional (user-friendly) information for operators - then you may consider to use less screens but with features improving information on screen, e.g. 'screen title from response variable' (so from 'Identification' property of variable), control element with switching direction, ability to display text from reaction matrix in the controls with RV and CO value, setting 'replace in screen' to display additional, manually created screen elements linked to (substituted, e.g. interlocking) variables etc.
    • you may copy&paste interlocking conditions (or action + its conditions) between different command groups; the only pre-condition - groups must contain the matching list of variables for interlocking (both groups must contain entries: X01, X02 etc., but entries can be linked with different variables). So you may e.g. create in Editor a "dummy" command group (not used in the Runtime) storing a kind of "template" - all general/substituted variables and interlocking conditions which shall be used in any group.
    • the user in the Runtime may call the first-stage of command from context menu, then the command screen linked to switching actions can be reduced to cover only interlocking text/list and execute/cancel buttons - common for any device. The text of entry in a context menu can be configured using macros - to reduce the quantity of context menus and display user-friendly information.
    • if you are communicating with control center via zenon Process Gateway - then maybe you can dynamically disable commands while system is in local mode. Then instead to add more interlocking conditions in groups - you may prevent the reception of commands from remote. For example zenPG IEC870Slave has the possibility to disable reception of commands via variable linked to a T00 with IOA 2.

  3. #3
    Join Date
    30.03.2016
    Posts
    39

    Default Re: Control from many sides to Substation

    Quote Originally Posted by ursulak View Post
    >I just did the solution for this problem was using an internal variable to decentralize the command authorization and integrate in each interlocking of command processing for each devices.
    Your use-case is absolutely normal (in general, maybe not in detail, each system is a little bit different), the solution - basing on interlocking conditions basing on general internal variables - the recommended one .
    But unfortunately - as you have written - the workload to implement the solution increases with each new command group . This is a "price" for open possibilities of the system characteristics like e.g. emergency controls, special routines for only parts of the system, etc.
    We know from zenon users the 2 kind of wishes: to have possibility to implement in zenon a project covering any use-case and - to have simplest-possible, fast configuration and pre-defined routines - to lower efforts in project enhancements. Unfortunately these 2 wishes are contradictory and we are still looking for ideas for features lowing these efforts. If you have some idea what exactly will support your use-case - please do not hesitate to share it.

    Hints:
    • keep the quantity of Command Groups as low as possible. Use command groups basing on substituted references - to response, command and interlocking variables, e.g.: response: *_RV; command: *_CO: interlocking: *_OpnEna, *_ClsEna, etc. Than you will be able to use single command group for switches represented in different devices.
    • before creating commands - plan the substitution and rename process variables. It is much easier to use well substituted groups when zenon variables have suitable names. Please note that when the iec850 driver communicates on 'Symbolic Address' then variables of all devices can be renamed to follow syntax suitable for substitution; and the variables of offset-basing drivers like iec870, dnp3 etc. could be renamed too.
    • if the reason to use many command groups are many command screens - because you want to display different additional (user-friendly) information for operators - then you may consider to use less screens but with features improving information on screen, e.g. 'screen title from response variable' (so from 'Identification' property of variable), control element with switching direction, ability to display text from reaction matrix in the controls with RV and CO value, setting 'replace in screen' to display additional, manually created screen elements linked to (substituted, e.g. interlocking) variables etc.
    • you may copy&paste interlocking conditions (or action + its conditions) between different command groups; the only pre-condition - groups must contain the matching list of variables for interlocking (both groups must contain entries: X01, X02 etc., but entries can be linked with different variables). So you may e.g. create in Editor a "dummy" command group (not used in the Runtime) storing a kind of "template" - all general/substituted variables and interlocking conditions which shall be used in any group.
    • the user in the Runtime may call the first-stage of command from context menu, then the command screen linked to switching actions can be reduced to cover only interlocking text/list and execute/cancel buttons - common for any device. The text of entry in a context menu can be configured using macros - to reduce the quantity of context menus and display user-friendly information.
    • if you are communicating with control center via zenon Process Gateway - then maybe you can dynamically disable commands while system is in local mode. Then instead to add more interlocking conditions in groups - you may prevent the reception of commands from remote. For example zenPG IEC870Slave has the possibility to disable reception of commands via variable linked to a T00 with IOA 2.

    Ursula,

    Quote Originally Posted by ursulak View Post
    [COLOR="#808080"]>
    Please note that when the iec850 driver communicates on 'Symbolic Address' then variables of all devices can be renamed to follow syntax suitable for substitution; and the variables of offset-basing drivers like iec870, dnp3 etc. could be renamed too.
    When I red this I became very happy. This will reduce our commandgroups a lot. So I tried but It looks like that the command processing is still looking at the name

    I have change the setting in the driver ( to Symbolic Address)
    Then I have added for every var(61850) used in the commandgroup a symbolic Adress. (e.g BAY_SWITCH_RV;BAY_SWITCH_CO;BAY_SWITCH_ENAOPN;BAY_ SWITCH_ENACLS
    Then I made a new commandgroup and used the symbolic Adress in the Dialogs and the Interlocking Vars. (*_RV for the group;*_CO for the actions;*_ENAOPN;*ENACLS for the Interlocking var)
    After this I set all the Switching objects used in this commandgroup to the right commandgroup (Var properties Write Set Value)
    After code generation I got error messages.
    "Command group 'Command'-variable 25k_V103!AA1J1Q03A1CTRL/VSCSWI1/Pos/Oper.ctlVal[CO']": Response variable'*_RV'does not exit

    I got this error for every switchobject in the commandgroup.

    Did I forgot something??

    Thanks in advance
    Last edited by Joulzer : 9th February 2017 at 14:59

  4. #4
    Join Date
    01.07.2008
    Location
    Salzburg, AT
    Posts
    983

    Default Re: Control from many sides to Substation

    it is to make the other way round:
    - 'Symbolic Address' = IEC61850 ObjectReference - e.g. 25k_V103!AA1J1Q03A1CTRL/VSCSWI1/Pos/stVal[ST] - for the driver
    - variable names - e.g. BAY_SWITCH_RV; BAY_SWITCH_CO; BAY_SWITCH_ENAOPN; BAY_ SWITCH_ENACLS - for the user of Editor and Command Processing

    so make sure that the variable property 'Symbolic Address' contains valid 850-references and that in the driver configuration - on tab 'Basic Settings' - the radio-box 'Symbolic address' is selected (and not the 'Variable name').

  5. #5
    Join Date
    30.03.2016
    Posts
    39

    Default Re: Control from many sides to Substation

    Quote Originally Posted by ursulak View Post
    it is to make the other way round:
    - 'Symbolic Address' = IEC61850 ObjectReference - e.g. 25k_V103!AA1J1Q03A1CTRL/VSCSWI1/Pos/stVal[ST] - for the driver
    - variable names - e.g. BAY_SWITCH_RV; BAY_SWITCH_CO; BAY_SWITCH_ENAOPN; BAY_ SWITCH_ENACLS - for the user of Editor and Command Processing

    so make sure that the variable property 'Symbolic Address' contains valid 850-references and that in the driver configuration - on tab 'Basic Settings' - the radio-box 'Symbolic address' is selected (and not the 'Variable name').
    Thanks that makes sense ��
    Now i untherstand the radio button in the driver and why its default in symbolic address

Similar Threads

  1. automatic switching (substation automation)
    By elsoportar in forum zenon Energy Edition
    Replies: 3
    Last Post: 14th April 2015, 12:20
  2. Message control
    By ziadnajjar in forum zenon Network
    Replies: 3
    Last Post: 24th June 2014, 07:33
  3. Message Control
    By navaneet in forum zenon Network
    Replies: 10
    Last Post: 2nd May 2014, 12:00
  4. Tab Control
    By anahita in forum VBA
    Replies: 2
    Last Post: 20th September 2011, 22:49
  5. Command Control
    By yara in forum Drivers
    Replies: 2
    Last Post: 7th December 2010, 14:49

Posting Rules

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