Experimental Physics and
| |||||||||||||||
|
Hi Sangwon, As you say, possible limitations in network traffic processing might be something that affects Gateway operation on VMs. But I would expect this only to happen if a Gateway is very busy and/or forwards large amounts of data, e.g. images. Channel Access' detection of unresponsive IOC connections is based on two mechanisms: The beacons (by default 5065/UDP broadcasts) sent by the IOC (by default every 15 seconds) must reach the Gateway, which requires the caRepeater program to be running on the Gateway host before the Gateway starts. If the Gateway does not receive a beacon within twice the configured beacon period, it uses the TCP connection to send a Channel Access alive message to the IOC. If the IOC does not return that alive message within 5 seconds, the Gateway declares the connection unresponsive. Check if the IOC beacons are reaching the Gateway host. If that Gateway is not in the IOC's local network, the IOC needs to be configured to send beacons to the Gateway. Also check if the VM's system clock is updating smoothly. I have seen VMs with jumping system clocks, which may affect the described detection mechanism. Generally, I would suggest using a more recent version of base for the Gateway, e.g. 3.15.5. There is no problem running the Gateway on a different version than IOCs, and there are issues in Channel Access that have been fixed since 3.14.12.4 (December 2013). If you want a simple setup, create statically linked Gateway and caRepeater binaries. Those will not need an installation of EPICS Base to run. Good luck! ~Ralph On Wed, 29 Aug 2018 at 08:35, 윤상원 <[email protected]> wrote:
| ||||||||||||||
ANJ, 07 Sep 2018 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |