Was anyone around before EPICS was created? Only very old guys
What was life as a control system engineer? In industrial control, they were using tools similar to EPICS, but they only supported their line of I/O and were not extendable, nor open source. At the labs there was a large debate about VMS vs. Unix, I/O was CAMAC
(which was developed with close contact to the labs), and there was token ring vs. ethernet. Like today, the labs also built the real time links and timing that their machines required. There was a lot of code to write.
Were labs all creating their respective control system? Yes.
What was the impact of EPICS on this development process? When we started developing EPICS my estimate was that we would save 80% of the effort required prior to that. What we actually found was that having that tools set saved about 35% of our effort. It ends
up that a large part of the job is working with the physicists and engineers to understand the requirements. Reliability improved significantly. The ability to adapt to last minute requirements was also greatly improved. Science projects are notorious for
saving the statement of the most challenging requirements for late in the project.
What are other control systems used (particularly in the US)? ACNet at Fermilab, SLC at SLAC, Bevatron at LBL, RHIC and NSLS each have their own, and LANL had three different ones for their accelerators. These are the only ones I recall. There was one scripting
language NODAL, that was shared by others. At the same time as EPICS, there was a second group at LANL that had developed a communication protocol that evolved into Channel Access and of course, a WYSIWYG user interface. The big difference is that it had no
process database and was based on VMS. That line became a commercial product: VSystem. That was used at several labs that had CAMAC and VMS.
Why do you think they didn't switch to EPICS? Switching is hard. Anyone that had something working was probably better off not switching. Today, there is still some friction regarding OO technology. By some, EPICS is not considered to be OO for its lack of
using an object model. There are counter arguments to this. I would say that the ChannelFinder Service overcomes 50% of those arguments. Version 4 should overcome another 40% of them. Many of those used CORBA for communications. That is more a software bus
than a control system communication layer. Many of them are starting to move away from CORBA now.
Should EPICS be the sole and uncontested software/framework for accelerators? No
why or why not? Not everyone will agree that it has the appropriate software model.
What about high-level software? High level software has all been done as large clients to the best of my knowledge. We are moving some of these applications to middle layer services. I hope that other control system consider this approach. It allows some interoperability.
The large questions are: can we provide the communication mechanisms to serve all of these, continue to keep the interface narrow to support client interoperability, and provide the reliability and performance that satisfies everyone. Of course, there is the
question of people using it.
CSS, medm, edm, matlab, Qt... (labview, other?) CSS is a nice integrated operator toolset. However, it is not appropriate for rapid prototype development. Python and Qt are better for that. edm is a great tool - reliable and robust. There are none others that
provide that functionality with that level of performance and robustness. CSS has to become more reliable and have the performance improved.
Which one do you use, why and which one would you like to use? EPICS, CSS, version 4, middle layer services. We are using them because we need to move our technology forward when we are building new facilities. After they are operational, it is hard to change.
Should we all converge to CSS, another? Why or why not? CSS is a good place to go for new facilities. It is not yet solid - so existing facilities should only go into that water if they are using some specific application that they need. In about 8 months,
I hope to say that I think it should be the direction everyone is taking. There will always be a place for Python and Qt. A robust layer - like the one that is being employed for CSS "pvManager" would be a huge benefit to python HMI developers.
Bob