IEC61850 Client driver, when e.g. variable */Xxx/Oper.ctlVal[CO] is advised, polls the data object - sends mms.read( *$CO$Xxx ). According the Standard, part -8-1 Ed2 with TISSUE#1288, this request is not mapped and may result in non-deterministic behavior of a 850-server. According the Standard the only valid read request with FC=CO is the Select service - mms.read( $CO$Xxx$SBO).
IEC61850 Client driver, when e.g. variable */Xxx/Oper.ctlVal[CO] is advised, polls the data object - sends mms.read( *$CO$Xxx ). According the Standard, part -8-1 Ed2 with TISSUE#1288, this request is not mapped and may result in non-deterministic behavior of a 850-server. According the Standard the only valid read request with FC=CO is the Select service - mms.read( $CO$Xxx$SBO).
Data of functional constraint CO is not polled anymore; CO-variables are now "write-only":
In the Runtime variables Oper.ctlVal*[CO] stay empty until user set the value. Variables Oper.Test[CO] and Oper.Check[CO], if created, show the latest set value; and after RT start or communication reconnect - 0. Other CO-variables in the Runtime, if created by user mistake, have no value.
In zenon Logic variable ctlVal keeps value 0 (also after execution of FB IEC61850_OPER); the use of FB is still the only legal way to execute a command, the creation of ctlVal - to license the use.
Note: some 850-servers on the market are misinterpreting the read of any CO object as Select service. Then the general poll of CO data causes that object is Selected.