![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||
|
Hi Vivien, On Thu, 12 Dec 2024 at 08:51, LORIOT Vivien <VIVIEN.LORIOT at cea.fr> wrote:
The PINI field made a lot of sense back in the distant past, when the IOC was always running in the controller slot of a VME crate. Powering on the crate meant powering on the I/O and the IOC - this was always happening at the same time. PINI could be used to initialize the I/O, bring it to a safe state etc. With intelligent remote controllers, IOC and device can power up and down independently, network can go away and come back. The device may not be connected when the IOC is initializing and instead be available at any time later. The device may go down while the IOC is running and come back later. The IOC may reboot while the device continues to work perfectly fine. The network might make the device unavailable at any moment for any time. As a result, in many if not most cases, PINI will not run when it should and will not do what you want it to do. So I shut it off and introduced `bini` as a way of specifying behavior at device connect. If you look at, e.g., StreamDevice, which is also handling remote intelligent controllers, its `@init` exception handler is implementing a similar concept. https://paulscherrerinstitute.github.io/StreamDevice/processing.html#init Almost always, reading the current value from the device is what you want to happen whenever the device appears (or re-appears), and that's why `bini=read` is the default for the OPC UA support. Cheers, ~Ralph
| ||||||||||||||
ANJ, 13 Dec 2024 |
![]() · Download · Search · IRMIS · Talk · Documents · Links · Licensing · |