command processing for setpoint values, responsvalue question.

[Tobiasto]

Hi

I'm using zenon energy edition 8.1 using IEC 60870 driver to a RTU.
To write analog setponit values to the RTU, I'm using command processing, one setpoint variable T50 and responsevariable T36.
As soon as the T50 value is recieved in the RTU, its looped back to a T36 variable for indication of actual setpoint. 
The command processing dialog is called up from a numeric field, under write set value via "Command Processing", this is working as expected.
Now to my question, when using the checkbox "propose current value", zenon is taking the current value of the commandvariable T50 and put it in the numeric inputfield, as a "startvalue", however, I would like to have the responsvalue copied there instead, is that possible?

My problem is that setpoint can be changed from other systems also, zenon is not the only scada.
If I restart Zenon, the T50 variable is zero, so proposed value will be zero, this mayby can be fixeed with variable remanence, but if other system is modifying setpoint in the RTU, proposed value in zenon is not relevant anymore, thats why I think responsvalue would be better as propose current value.

 

[ursulak]

I understand your point, but the command screen does not have such feature. You can display in screen the value of RV but the editable value of the command is another field - this with value of action variable. An automatic value transfer between those fields is not possible.

I can imagine a work-around with involving additional variables and zenon Logic. Or maybe AddIn "magic" in open command screen, i'm not sure. But I suppose this would be too complex try.

[HMIdeveloper123]

I understand your point, but the command screen does not have such feature. You can display in screen the value of RV but the editable value of the command is another field - this with value of action variable. An automatic value transfer between those fields is not possible.



I can imagine a work-around with involving additional variables and zenon Logic. Or maybe AddIn "magic" in open command screen, i'm not sure. But I suppose this would be too complex try.

Does the 870 driver write to PLC as soon as the command varaible value is changed within Zenon database or only when a specific write set value (via function or command prceossing screen) is applied?

Could you use variable allocation to map the respose varaible to the command varaible? That way it would keep in sync if altered externally. You could maybe only trigger allocation update when the WSV screen is opened?

[ursulak]

All zenon drivers, so also IEC870, write to PLC when the zenon Runtime pokes (transfers) the new proposed variable value to the driver. In zenon variables have the updated value first when PLC provides it. The Runtime pokes the value by any kind of set value operation, e.g. from user dialog, from write set value function, from allocation, from recipe, from command processing action etc.

BTW: in zenon Runtime the value of this written to PLC variable changes only when and after the PLC sends this value back. Thus, e.g. after an allocation the change of target variable means that the PLC not only got this value but also - depending the communication protocol - either acknowledged the command or provided the update back to master (driver).  

The command processing when linked to variables, is suppressing other 'set value' operations (by user dialog or functions), but not if the command variable has defined action 'set input value' of kind "set value". But exactly this action is used according the post from Tobiasto, thus in this project 'write set value' operations on command variables are not suppressed.

@HMIdeveloper123: Sorry, but your idea with allocations is wrong, any try to "map" the current response variable value to the value of command variable will immediately result in a command. The solution for Tobiasto's use case could be only some kind of mapping of the current RV value as the initial value into screen element for CO variable; and not directly as CO variable value. But there is no simple way to have it.

[Tobiasto]

Thanks for the information Ursulak, I guess I have to accept the behavior as it is.