Action buttons not enabled (interlocked) Command processing

[Joulzer]

Hi,

We have implemented command processing with VBA for some time and thats working fine.

Nou we like to do the command processing without VBA.

I have tried to follow the manual, until opening of the commandprocessing display everything works



I have created a commandgroup and command actions





I have created Response var and en Command var



and link them to correct commandgroup



I did not configure the Authorization of the action buttons in the commandprocessing display So I was expecting that the action buttons should be enabled (Not interlocked)



I tried everything but I can not manage to enable the buttons without using VBA.

Can you help me please is there a way to debug the commandprocessing screen

We use 7.50 built 31997

Thanks in advance

[ursulak]

There could be few reasons why in command screen the action buttons are disabled. This is complex module (according the rule: "be careful what you wish, you may get it all" )

1. In Editor, in Output window, check if there are some errors/warnings (red or orange) messages after you compiled all modules - toolbar icon 'Create all RT files'.
2. Make sure that the Frame of command screen does not have setting 'Frame can be opened multiple times' and have 'Always in the foreground'. Else it may happen that the second instance of the screen is open in the background (but you do not see it) and blocks the visible execution.
3. In project settings - 'Automatic Line Coloring' - 'ALC configuration' - 'Interlockings': set all 5 topologic interlocking to "do not check" (you may activate them later - when you will sure that CO are working). Else the ALC may protect the switches and disconnectors against risk operations.
4. include in command screen (ev. temporarily) the control element: 'Information' - 'Response variable (status)'. Only when variable has status SPONT and NET_SEL the action buttons are available (so not by INVALID, OFF - communication problems; and not when other zenon network client has the command screen open for the same RV).

The kind of "debugging" for command screen are SYSDRV variables of Theme "[Command Processing]".

[Joulzer]

There could be few reasons why in command screen the action buttons are disabled. This is complex module (according the rule: "be careful what you wish, you may get it all" )

1. In Editor, in Output window, check if there are some errors/warnings (red or orange) messages after you compiled all modules - toolbar icon 'Create all RT files'.
2. Make sure that the Frame of command screen does not have setting 'Frame can be opened multiple times' and have 'Always in the foreground'. Else it may happen that the second instance of the screen is open in the background (but you do not see it) and blocks the visible execution.
3. In project settings - 'Automatic Line Coloring' - 'ALC configuration' - 'Interlockings': set all 5 topologic interlocking to "do not check" (you may activate them later - when you will sure that CO are working). Else the ALC may protect the switches and disconnectors against risk operations.
4. include in command screen (ev. temporarily) the control element: 'Information' - 'Response variable (status)'. Only when variable has status SPONT and NET_SEL the action buttons are available (so not by INVALID, OFF - communication problems; and not when other zenon network client has the command screen open for the same RV).

The kind of "debugging" for command screen are SYSDRV variables of Theme "[Command Processing]".

This is working fine now.

Now I try to add interlock to the action buttons. But I'm a little bit confused . Where do you have to define the interlock variable. In command processing or at interlockings. At the command processing section you can define interlocking variables for every command group. But where do use you use them?
And how does the search and replace works for interlock variables. We working withe energy edition.

[ursulak]

Now I try to add interlock to the action buttons. But I'm a little bit confused . Where do you have to define the interlock variable. In command processing or at interlockings.

The additional variables which shall be used in interlocking conditions by actions in Command Processing, you should link in node 'Variables' of the command group.

The most interesting features of interlocking conditions linked to the action are:
- you can use wildcard * in the name of variable linked to the command group, similar like by RV and CO variables. In the Runtime then the * char will be replaced with the same text like * part of response and command variable names;
- when in the Runtime an interlocking condition prevents execution of the command, then the user will be informed - in the command screen - control element 'Interlocking text' or 'Interlocking List' - with the text defined by you in Editor.
- an user having suitable authorization level may then still force execution (control element 'Unlock' or 'Unlock all'), but only if you define that this paticular condition is 'Unlockable'. Conditions without this setting cannot be overrouled by users.
- each action can have own set of interlocking conditions, e.g. action to CLOSE may have different conditions as action to OPEN the switch. Which conditions will be then checked before execution decides not the button in the screen, but the action; So interlocking is also protecting the execution if the user in the Runtime will choice action already via context menu, not using the command screen.
- in Editor you may copy&paste interlocking conditions between actions, also between actions in different command groups.

Where to create an interlocking condition shows the screenshot.

[Joulzer]

The additional variables which shall be used in interlocking conditions by actions in Command Processing, you should link in node 'Variables' of the command group.

The most interesting features of interlocking conditions linked to the action are:
- you can use wildcard * in the name of variable linked to the command group, similar like by RV and CO variables. In the Runtime then the * char will be replaced with the same text like * part of response and command variable names;
- when in the Runtime an interlocking condition prevents execution of the command, then the user will be informed - in the command screen - control element 'Interlocking text' or 'Interlocking List' - with the text defined by you in Editor.
- an user having suitable authorization level may then still force execution (control element 'Unlock' or 'Unlock all'), but only if you define that this paticular condition is 'Unlockable'. Conditions without this setting cannot be overrouled by users.
- each action can have own set of interlocking conditions, e.g. action to CLOSE may have different conditions as action to OPEN the switch. Which conditions will be then checked before execution decides not the button in the screen, but the action; So interlocking is also protecting the execution if the user in the Runtime will choice action already via context menu, not using the command screen.
- in Editor you may copy&paste interlocking conditions between actions, also between actions in different command groups.

Where to create an interlocking condition shows the screenshot.

This was the answer that I was looking for. Thanks!!!!!

Finally I got it. I was looking for the condition where to create. The picture was very clear.
I can not find this in the manual : Energy Edition "Command processing" I have played with it and works fine. Easyer than vba.

Last question. Is it possible to disable the on step earlier. Now you first have to press the button than you can see if the opbject is interlocked for open ore close

Maybe I ask to much

[markclemens]

Hi,

As you can define different interlocking variables and conditions for open and close, you choose the direction first in the two-stage command processing and then the appropriate interlocking condition is displayed.

It is possible to use the context menu in combination with the command screen. In the context menu you would select OPEN or CLOSE or ON or OFF, pre-selecting the direction. The command screen would open with the direction pre-set.

For this you need to crate a context menu and configure it for command processing. Then link the context menu at the element, e.g. the combined element representing a breaker, in the symbol in your symbol library.

Best regards,
Mark

[Joulzer]

Hi,

As you can define different interlocking variables and conditions for open and close, you choose the direction first in the two-stage command processing and then the appropriate interlocking condition is displayed.

It is possible to use the context menu in combination with the command screen. In the context menu you would select OPEN or CLOSE or ON or OFF, pre-selecting the direction. The command screen would open with the direction pre-set.

For this you need to crate a context menu and configure it for command processing. Then link the context menu at the element, e.g. the combined element representing a breaker, in the symbol in your symbol library.

Best regards,
Mark

Thanks I will check this

[vitmi]

There could be few reasons why in command screen the action buttons are disabled. This is complex module (according the rule: "be careful what you wish, you may get it all" )



1. In Editor, in Output window, check if there are some errors/warnings (red or orange) messages after you compiled all modules - toolbar icon 'Create all RT files'.

2. Make sure that the Frame of command screen does not have setting 'Frame can be opened multiple times' and have 'Always in the foreground'. Else it may happen that the second instance of the screen is open in the background (but you do not see it) and blocks the visible execution.

3. In project settings - 'Automatic Line Coloring' - 'ALC configuration' - 'Interlockings': set all 5 topologic interlocking to "do not check" (you may activate them later - when you will sure that CO are working). Else the ALC may protect the switches and disconnectors against risk operations.

4. include in command screen (ev. temporarily) the control element: 'Information' - 'Response variable (status)'. Only when variable has status SPONT and NET_SEL the action buttons are available (so not by INVALID, OFF - communication problems; and not when other zenon network client has the command screen open for the same RV).



The kind of "debugging" for command screen are SYSDRV variables of Theme "[Command Processing]".

Hello,

I've got exactly the same problem with the disabled action buttons in Command screen. Using Zenon 10 with demo license.
I followed your 1-4, please check it:
1. No errors, just warnings as below.

2. Checked and these are not ticked.

3. I set all 5 topologic interlocking to "do not check".

4.

I included compiled log file in the attachement.
Thanks

[ursulak]

while there is no communication with the IED (i see on your screenshot that the stVal variable is INVALID) - how do you expect to send a command? 

[vitmi]

while there is no communication with the IED (i see on your screenshot that the stVal variable is INVALID) - how do you expect to send a command? 

Hi, Ursulak,
I'm following the Energy edition training. It was working normally before I've implemented command processing.
Could you be so kind and advice me how to solve this? I'm not sure what am I missing here.
Thank you.