Hello everybody!
Can some one explain me, why I can not see current value of ESM_DATA.ESM_INFOS[1].TICK_COUNT inside of my plc code and WATCHES.
(The program is loaded and running on this core of plc)
But TICK_COUNT value can be seen via HMI on webpage!
According to
https://www.plcnext.help/te/Programming/IEC_61131-3/System_variables/System_variables_Part_2.htm
It should be always 0, but what is on data exchange with HMI?
RAW response: {“apiVersion”:“1.8.0.0”,“projectCRC”:3101904310,“userAuthenticationRequired”:true,“id”:“g3931455”,“variablePathPrefix”:“Arp.Plc.Eclr/”,“variables”:[{“path”:“ESM_DATA.ESM_INFOS[1].TICK_COUNT”,“value”:“1791428”}…
I use FW2022.3 and PLCNext engineer 2022.3, AXCF2152.
It’s pretty annoying that isn’t working any more…
Hopefully they will fix it soon
-Emil
from the help file;
https://www.plcnext.help/te/Known_issues.htm
Task-handling variables The content of these system variables is permanently set to 0
* :
* ESM_DATA.ESM_INFOS[*].ESM_TICK_COUNT
* ESM_DATA.ESM_INFOS[*].ESM_TICK_INTERVAL
Known for firmware2020.3 or newer on all supported PLCnext Control devices
There are currently no plans to change this behaviour (i.e. TICK_COUNT = 0). This Struct element would have been removed altogether, but the change in the layout of the structure might break existing applications, so it has been left in.
We have reproduced the strange behaviour of the REST interface reported by Oleksandr, and we are investigating it.
This artifact is useful as life-bit indicator.
But nevertheless, we wish to have clearly defined behavior and meaning of system variables.
Dear Martin, we are looking forward for the conclusion of your investigation.
Best regards.
We have now heard from the developer of the HMI service.
The conclusion is that the documentation is correct - the system variable ESM_DATA.ESM_INFOS[*].TICK_COUNT is always zero. However when a request for this system variable is made from a REST client, the HMI server does not return the value of that system variable (which is always zero), but instead it returns a different value that looks like a tick count.
We have asked for the documentation to be updated, to include this behaviour.
To clarify one of my earlier comments - there is an open requirement with our developers to provide a non-zero value for the TICK_COUNT system variable, but this feature has not yet been scheduled.