Dont overwrite all PLC Registers of a Block if only one Register is set
The CERN requirement is, to be able to either keep PLC-values at startup, or to ovewrite them with local values:
A register can be retentive: this is a constant or persistent data which require an initial-value and which is retained in case of controls reset (e.g. persistent settings, configuration parameters, etc.). The controller expert can choose to provide the initialization value from the controller or from the FEC: MASTER: The data is retentive and its initial-value is stored in the controller memory. SLAVE: The data is retentive and its initial-value is provided by the client process. NONE: The register does not require any synchronization (volatile data).
IMO, this behavior anyhow should be the default. In any case we should take care to dont overwrite all Registers of a Block if only one Register actually is set ( do a "get" before the "set" in such a case )
Another solution could be a constant-register, which is set only once during startup. Not possible to change during runtime. The used value could be defined in the silecsdesign ( or in the deploy, if it is device-specific ?)
Since it actually is not related, we should remove the volatile-field.
Activity
Alexander Schwinn @aschwinn wrote on Fri, 29 Sep 2017 14:58:47 CEST :
changed milestone to %2.1.0
By Alexander Schwinn on 2018-09-04T07:45:36 (imported from GitLab)
-
Alexander Schwinn @aschwinn wrote on Fri, 05 Jan 2018 10:02:12 CET :
IMO, this behavior anyhow should be the default.
To be more concrete: Each setting field should be initialized by it's controller-value on startup. This is already done at the end of
Connection::doOpen. So further action required here.In any case we should take care to dont overwrite all Registers of a Block if only one Register actually is set ( do a "get" before the "set" in such a case )
We could provide a setRegister(...) method for the user which does exactly that.
MASTER: The data is retentive and its initial-value is stored in the controller memory
--> For Constants this should result in an usual acquisition register (IMO no good style, since the setted value will be lost on plc-flash)
--> For Settings this should result in an usual setting register
SLAVE: The data is retentive and its initial-value is provided by the client process
--> This should result in an configuration register ( and later on in a fesa-config-field )
--> Separate "Configuration Block" is needed. Because on startup configuration registers need to be send to the controller, where setting registers need to be received from the controller --> but one only can send /receive a whole block. --> Use a setting block and change access type to acquisition after init-step.
By Alexander Schwinn on 2018-09-04T07:45:36 (imported from GitLab)
-
Alexander Schwinn @aschwinn wrote on Tue, 30 Jan 2018 17:56:47 CET :
mentioned in commit 1b852120
By Alexander Schwinn on 2018-09-04T07:45:37 (imported from GitLab)
-
Alexander Schwinn @aschwinn wrote on Tue, 30 Jan 2018 18:03:11 CET :
Implementation Done.
- Separate Configuration-Block with Configuration Register
- Internally handled like a RW Block
- FESA Configuration field created for each configuration reg.
- FESA AcquisitionProp. created for each configuration block
- FESA only can write to the block
- On init, the FESA device-specific value is written to the block
By Alexander Schwinn on 2018-09-04T07:45:37 (imported from GitLab)
-
Alexander Schwinn @aschwinn wrote on Wed, 31 Jan 2018 13:10:33 CET :
mentioned in commit 67cf29a3
By Alexander Schwinn on 2018-09-04T07:45:37 (imported from GitLab)