Experimental Physics and
Industrial Control System

Ben Franksen via Tech-talk <tech-talk at aps.anl.gov> · Thu, 18 Feb 2021 18:30:13 +0100

Am 17.02.21 um 15:08 schrieb Delahaye Olivier via Tech-talk:
> About the upgrade of our EPICS version, I think we could upgrade
> first our linux IOCs without changing for the new pvAcess protocol
> (remaining on Channel Acess protocol).
> 
> In a first step, we can live with 2 different versions of EPICS.
> (3.14 for our IOCs running on VxWorks) and 7.0 for our linux IOCs.

I think nowadays this is probably okay. A year ago I would have
recommended 3.15 but my impression is that 7.0 has matured enough in the
meantime so as to no longer be a moving target.

> In a second step : switch to pvAcess protocol. By the way, even if
> Channel acess is still there, is it still maintained in the same
> manner than pvAcess protocol ?

I won't get any new features, but it is not gpoing to go away any time
soon. AFAIK it will be maintained in the sense of "kept along and fixed
to compile on new archs and compilers" for many years. It is also, and
has been for quite some time, an extremely stable piece of software.

> In a last step and because it's risky, we have to study the impact on
> our oldest VxWorks IOCs. We have quite a lot of drivers running on it
> (epecially for RF part) ant it might not be so easy to switch on 7.0
> version.

My recomendation would be to start doing this in parallel. The EPICS OSI
(OS-independent) API is available since 3.14. Most of what vxWork offers
has a corresponding OSI thing to replace it. For someone who once wrote
an EPICS driver for vxWorks the porting is not too hard. I have done it
for more than 20 drivers/device supports. After the second or third you
won't have much difficulty with the rest, typically, except if they do
something very non-trivial. But of course you need to allow for test time.

> My wish will be to use only linux IOCs but it's another story (need
> to check if all equipments are ready for that, it might request huge
> investments).

As the years go by this is becoming more and more a viable option.
Still, there are some things for which I would say a real real-time
system like RTEMS is still the better choice. For instance, we could
recently improve the behavior of a piece of software I wrote years time
ago (an energy ramp machine, a sequencer state machine plus a host of
records) by moving it from a soft IOC on Linux to an mvme5500 board with
RTEMs. The timing became /a lot/ better, allowing us to ramp faster and
in smaller steps and still with less disturbances.

Cheers
Ben
-- 
I would rather have questions that cannot be answered, than answers that
cannot be questioned.  -- Richard Feynman

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System