Re: Same device on multiple IOCs

[Rea Domitrović via Tech-talk <tech-talk at aps.anl.gov>]

Hi Ralph,

thank you for the prompt response. My answers to your questions:

> Is your multiplexer a piece of software that you implemented in  StreamDevice, one level lower in Asyn, or is it a separate piece of  hardware/software that does the multiplexing? How is the multiplexer controlled?

The multiplexer is a piece of hardware, using StreamDevice support over TCP for control.

> Why do you want to multiplex in the first place, instead of having a separate Asyn port for each accelerator?

Because on each accelerator we have two Faraday cups (4 total) whose signals are multiplexed into one picometer per accelerator. This is a limitation of the fact we have one physical multiplexer (with two multiplex cards) and only two picometers. To avoid multiplexing we would need to have four picometers.

Thank you for the feedback regarding the typical design approach of EPICS; I was brainstorming without fully understanding how the underlying system works.

Cheers,
Rea



From: Ralph Lange <ralph.lange at gmx.de>
Sent: Monday, October 5, 2026 12:03
To: EPICS Tech Talk
Cc: Rea Domitrović
Subject: Re: Same device on multiple IOCs
  



Hi Rea,

 

On Mon, 5 Oct 2026 at 11:11, Rea Domitrović via Tech-talk <tech-talk at aps.anl.gov> wrote:
 


we're currently reworking our control system, and we have some situations where the same device might need to be controlled by multiple IOCs.
    


Uffa.
Multi-master is a recipe for trouble, you know that.

 


One situation is an S7 PLC controller which controls a whole bunch (ion sources, beam focusing, terminal voltage), and we wish to separate its function into multiple IOCs for modularity.
    


Unusual.
For doing the split on the device connection, the feasibility depends on the protocol that you want to use to access the S7.
Otherwise, you can try to have one IOC doing the (low-level) communication to the S7 and the functional parts in separate IOCs that write to the comms IOC. That would require stable interfaces between them, though.

 


Another is a StreamDevice (i.e. Asyn IP) multiplexer with multiple output streams, each output stream dedicated to one accelerator.
    


Not exactly sure what you mean by that. StreamDevice is a Device Support module for EPICS, on top of Asyn. Is your multiplexer a piece of software that you implemented in StreamDevice, one level lower in Asyn, or is it a separate piece of hardware/software  that does the multiplexing? How is the multiplexer controlled?


Why do you want to multiplex in the first place, instead of having a separate Asyn port for each accelerator?

 


 1. Are software ports created by one IOC exposed to other IOCs? So for example if I make Asyn IP port Mux0 in one IOC, does writing  to that port from a different IOC work?
    


No. Asyn ports are within the driver, only visible within Asyn on that IOC.

 


2. Is it possible to control the same device from multiple IOCs, and what is the recommended way to do so? If 1 is True, then I was thinking of making a "holding" IOC which only exposes all the ports  to which then the IOCs containing records can write.   


Not on that layer, not in that way.


Sometimes (e.g., with OPC UA, which can be used for the S7) you can do that on the device layer by having multiple IOCs each open a connection to the same device.
If the device only allows one connection, only one IOC will control it.


Inside an EPICS IOC process, you implement and configure a process database, with atomic "records" that hold input or output values. These records can point their inputs and outputs to hardware (local or remote)  or to other records, which may be hosted on the same IOC or on a different IOC.
So, cross IOC connections work, but only between records, not between driver constructs.


I would say: For better Tech-Talk suggestions, you need to provide a bit more detail about your problem.
The design ideas you presented do not match the usual EPICS approach. Telling you how to force-push what you want ... would lead to a weird, quirky system and ultimately be bad advice.


Cheers,
~Ralph 


      
Oprez: Ova poruka stigla je od vanjskog pošiljatelja. Prije otvaranja poveznica ili privitaka provjerite pošiljatelja. Caution:This email originated from an external sender. Please verify the sender before opening links or attachments.