Re: PVXS IOC Philosophy

["Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov>]

Looks like we gave several reasons to encourage continuing with IOCs, records, using PVAccess just like Channel Access.

 

Just like when you get a new car, you use the steering wheel, brake, and accelerator. We’re technically minded, there might be an urge to start hacking the CAN bus, but that’s not necessary if what you want to do is simply drive the car, and shouldn’t be your highest priority.

 

What we might be missing is some good examples for going beyond IOCs and records.

 

As Timo wrote, ‘the main way to take advantage of them is to use the “group PV” capability’.

With “makeBaseApp.pl -t example” you now get a “circle.db” example. It creates a PVA structure that combines data from several records. Clients can receive ‘atomic’ updates from several records by reading that structure. But those clients then typically are custom clients. EPICS meetings could be a good way to present some real-world examples for using “groups” in production.

 

For fully custom servers and clients, SNS presented an example at the 2015 ICALEPCS. Hesitant to post web links since tech talk might garble them, but search JACOW or ICALEPCS web sites for “EPICS V4 Evaluation for SNS Neutron Data“. In short, we used PVAccess because the server and client libraries existed, performance was very good, we could use “pvget” to check if the server generates something useful, and to some extend you can even use a generic client to show “neutrons/protonCharge”. So instead of using some completely different protocol, we took  PVAccess, but it’s mostly between a custom server and clients, and it’s pretty much the only example we have for custom data, since we generally prefer interoperable clients and servers.