Experimental Physics and
Industrial Control System

Matthieu Bec <[email protected]> · Fri, 20 Dec 2002 18:09:06 -1000

Hi Peregrine,
We just received Michelle, an instrument shared between Ukirt and
Gemini, and I noticed both behaviours, reported by Russell and when the
lines are busy. We're using vw5.4.2
operationally, I concluded it's not really a big deal for (1) unless you
power cycle the whole instrument: there's a chance the application comes
up faster and try access its portserver before it's ready. But since we
have our network switch on the same supply, those kinds of problem seem
inevitable (eg. vxworks trying to download before the link is up and
give up. Hopefully our UPS protects us from all that! and once the
portserver are up, we can cleanup the situation through the consoles.

The solution Ukirt adopted was split the database with serialIO, and
comment out your dbLoadRecords and tnetDevCreate at the same time.
for the 2nd problem, I had to set session timeouts on the various port
line, so it' has time to cleanup if the crate needs a brutal reboot.
Cheers,
Matthieu

Peregrine M. McGehee wrote:

Russell,
We have seen a similar problem where all network access on the IOC
hangs up when a port originally used by the tnetDrv is disconnected
by external users.
In the original discussion the feedback indicated that it may be
due to the old version (v5.1.1) of vxWorks that we are running - since
at least one other site (UKIRT) had ports frequently logged out
but did not experience our problem.
We have considered, but not yet implemented, changes to the driver
to deal with this.
- Peregrine
"Redman, Russell O." wrote:
For the most part, EPICS does a pretty good job of handling non-existent
hardware, through judicious use of the SIOL and SDIS fields.  I have just
encountered a gap in the system.  I will be using tnetDev to talk to a suite
of controllers through a terminal server.  I will not have the actual
controllers for another 8 months, but am developing the necessary parts of
the database now so I will be ready when they arrive.  I am looking for a
way to create dummy pseudo-terminal devices similar to those created by
tnetDevCreate, but without the need for a real terminal server on the
network.
The tnetDevCreate routine creates pseudo-terminal devices for the ports on
the terminal server.  This routine must run before iocInit, i.e. before any
of the simulation mode or disabling tools of EPICS is available. When
tnetDevCreate runs the terminal server port must exist and be configured
correctly or really bad things happen.  My startup code looks like:
  # Start serial drivers for terminal server
  hostAdd "harpts", "192.168.3.41"
  tnetDevCreate "/pty/0.", "harpts", 3003
  tnetDevCreate "/pty/1.", "harpts", 3004
  #tnetDevCreate "/pty/2.", "harpts", 3005
  #tnetDevCreate "/pty/3.", "harpts", 3005
  #tnetDevCreate "/pty/4.", "harpts", 3008
If I uncomment the last three lines (attempting to access ports that have
already been allocated by another task) tnetDev quite properly refuses to
make the connection, but seems to hang all network access for several
seconds.  During this period, channel access attempts to start the
CA_repeater, CA_TCP and CA_UDP, all of which fail because they cannot create
new sockets, and any attempt to read files using netDrv also fails.  This
leaves me with a catch-22: if I comment out the last three lines, the
database fails to load because "/pty/2.", "/pty/3." and "/pty/4." do not
exist, while if I uncomment the lines iocInit fails to create necessary
sockets and fails to read my initialization files.  There does not seem to
be a way to make dummy devices.
In the short term I can probably fix this by adding another terminal server
to the system, but my real concern is for the longer term when we will want
to run the database in a pure simulation mode with NO external hardware.  It
currently looks like we will need to plug in a spare terminal server to
allow tnetDevCreate to complete successfully, even though the database will
never use the devices in simulation mode.
Has anyone else encountered this kind of problem, and are there any clean
solutions?
Dr. Russell O. Redman
Tel: (250) 363-6917 | Fax: (250) 363-0045
<mailto:[email protected]>
National Research Council Canada | Conseil national de recherches Canada
5071 West Saanich Road           | 5071 West Saanich Road
Victoria, B. C. V9E 2E7          | Victoria, C.-B. V9E 2E7
Government of Canada             | Gouvernement du Canada

--
Matthieu Bec              Gemini Observatory
Tel: +1 808 9742557       670 N. A'ohoku Place
Fax: +1 808 9359235       Hilo, Hawaii 96720, USA

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System