How to use DSC EPICS I/O server outside the local subnet?

[Richard2950]

I have a computer that is running 3 EPICS IOCs simultaneously. The first one to start uses the default TCP port of 5065 for Channel Access communications, and the next two choose dynamically-allocated (i.e. random) TCP port numbers. The clients access them through shared variables bound to EPICS I/O servers set up through the DSC module. This works just fine on the local subnet, and the clients always find the servers regardless of what ports are being used. I have not been able to make this work when the client is outside the local subnet, though. For standard EPICS clients the configuration is done through the environment variable EPICS_CA_ADDR_LIST, but LabVIEW doesn't seem to use  those environment variables. How do I tell the clients where to go to find the servers? Do I use  the Distributed System Manager to add the IP address to the list? Do I need to worry about the non-standard ports being used by 2 of the IOCs?

[Charlie_P]

Good Afternoon Richard,

From 1.3.2 of CHAPTER 1 Configuration, "Proper configuration of CA for multiple subnets requires that CA name resolution (search requests) frames pass from CA clients to the targeted CA servers."  (http://www.aps.anl.gov/epics/EpicsDocumentation/AppDevManuals/ChannelAccess/cadoc_4.htm)

There is no way to set EPICS environmental variables with LabVIEW because the EPICS default values are compiled into LabVIEW.  LabVIEW will override all environmental variables' values with the EPICS server defaults when you connect to the server through LabVIEW.  As such, even if you
include your values in a configuration file, they will not be used.

The above information leads me to believe that there is no way to connect to an EPICS server hosted on a subnet which is different from that of the computer running LabVIEW.

[unclebump]

Could you get the EPICS system to talk modbus??

http://millenia.cars.aps.anl.gov/software/epics/modbusDoc.html

[Ben]

Hi Richard,

Plese forgive me if this does not help!

Have you tried changing the subnet masks to allow the cross subnet comm?

(again if you you knew this please forgive).

The bits of the subnet mask determine what part of the IP address is checked by the node. Witha subnet mask of "255.255.255.0", only packets with an IP address that have the same first three octets of the nodes address get through the hardware filter.

If node IP is

198.162.1.1

and sender is

198.162.0.1

and mask is

255.255.255.0

then the message gets tossed because the thidr octet does not match.

Change the subnet mask to

255.255.0.0

then the message makes it through.

Like I said if you knew this please forgive this distraction.

Ben

[Richard2950]

I think the solution may be to use a VPN connection. Unfortunately I don't have the hardware for that at the moment.