Project

General

Profile

Feature #7839

Add IOC support

Added by Richard Neswold over 4 years ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
ACSys/FE Framework
Target version:
-
Start date:
02/11/2015
Due date:
% Done:

0%

Estimated time:
Duration:

Description

In the ACSys framework, we've taken great care to keep ACNET protocol-isms out of the core. RETDAT / SETDAT / GETS32 / SETS32 / and FTPMAN messages are decoded and then handled in an internal, protocol-agnostic form. Replies are encoded back into the expected form. The core, however, operates in a superset of the protocols' requirements.

If we add encoders and decoders for Channel Access and add a process, or two, to handle the standard EPICS socket connections, we could make our front-ends participate in both ACSys and EPICS control systems! Our front-ends wouldn't use the EPICS database framework; we would be advertising and returning data from our devices. But to the outside world, we would look like an IOC.


Related issues

Blocked by Erlang Front-end Framework - Support #16195: Make the framework more control system agnosticNew2017-04-13

History

#1 Updated by Richard Neswold about 3 years ago

  • Project changed from 974 to Erlang Front-end Framework

Move to the proper project.

#2 Updated by Richard Neswold over 2 years ago

  • Blocked by Support #16195: Make the framework more control system agnostic added

#3 Updated by Richard Neswold over 2 years ago

After looking at the alarm and plot support, I realized the claims of being protocol-agnostic were a stretch. I created a new issue to fix this deficiency.

#4 Updated by Dennis Nicklaus over 2 years ago

A brief outline of some of the steps needed:

For Epics IOCs, "read requests" (monitors in CA/Epics speak) generally start with a UDP search request for the name of the PV being requested, and the owning IOC responds, then the channel creation proceeds. Our front-ends really ideally don't have any concept of which devices (by name or DI) that they contain. To make our framework react as an IOC, we'd have to
  1. Have a way for the front-ends to know what Epics devices they own, such as available through the lookup service, probably similar to how ca2acnet looks up which Epics devices it wants to find
  2. Then implement the relatively straightforward IOC behaviour of responding to search requests and establishing the CA channel. Both these first two would be an add-on to the framework much like acnet is added to our core framework.
  3. Then we implement the encoder/decoders mentioned above to attach to our drivers and get results to the requesting client
  4. Note that Epics monitors expect the IOC to have an intrinsic reply frequency, so that'd have to come along with the lookup response mentioned above and then used when connecting to the driver

Of course, we're not really very protocol agnostic when the main thing that our top readingloop in readset.erl is looking for is called an #acnet_request, but the idea is the encoders mentioned above translate the camonitor into a "#acnet_request".

#5 Updated by Richard Neswold over 2 years ago

Dennis Nicklaus wrote:

For Epics IOCs, "read requests" (monitors in CA/Epics speak) generally start with a UDP search request for the name of the PV being requested, and the owning IOC responds, then the channel creation proceeds. Our front-ends really ideally don't have any concept of which devices (by name or DI) that they contain.

Device names? No, the framework doesn't have that information. However, we did name the attributes used by the drivers. This was done deliberately so that we could access them in EPICs. I also want to be able to specify attributes by name in DRF3.

  • Note that EPIC monitors expect the IOC to have an intrinsic reply frequency, so that'd have to come along with the lookup response mentioned above and then used when connecting to the driver

So when the front-end gets its device names, it'll also get the default frequency. Cool.

Of course, we're not really very protocol agnostic when the main thing that our top reading loop in readset.erl is looking for is called an #acnet_request{}, but the idea is the encoders mentioned above translate the CA monitor into an #acnet_request{}.

We definitely let some ACNET-isms reach too deep in the framework...

#6 Updated by Richard Neswold 11 months ago

  • Category set to ACSys/FE Framework

Set category field.



Also available in: Atom PDF