Privacy and Security Notice

Archived Messages for CLAS_SLOW_CONTROL_1996@cebaf.gov: Report on CEBAF HALL B 1458 ARCNET hangup (fwd)

Report on CEBAF HALL B 1458 ARCNET hangup (fwd)

Mark M. Ito (marki@CEBAF.GOV)
Mon, 01 Apr 1996 13:48:21 -0500 (EST)

Hi Mark:
Feel free to post this report to the slow controls email list.

Report on Visit to CEBAF by Bert Yost and Mike Green of LeCroy Corp.

Bert Yost and myself visited CEBAF Hall B counting house on 3/21 to look
into reported hangups of ARCNET communications with the 1458 HV mainframes
installed there. The frequency of these hangups were reported to be
anywhere from an hour to a day or so. Upon our arrival Hall B personel
exercised a few 1458's with their EPICs control software and after an hour
or so were able to cause a mainframe to hangup on two different mainframes.
Even though the mainframe would not communicate on it's ARCNET port, it
still would allow RS-232 communication and the generation of a VT100 control
display. Hall B personnel also reported that the mainframe closest to their
VME/ARCNET controller seemed to have the most frequent problems.

Using a local PC with an ARCNET interface, we used "HVTEST" (LeCroy test
software) to run a monitoring test loop with one of the 1458's in the
counting house. This test executes a number of standard monitoring commands
at a high rate (much faster than the standard Hall B monitor rate of 1/3
HZ). After 500 loops through this procedure (2-3 hours) we did not observe
the 1458 ARCNET to hangup.

To make a long story short, we since have concluded that the most likely
problem with the CEBAF configuration is the ARCNET cable length between
mainframes and/or the host controller. This solution was first considered in
light of the type of testing done at LeCroy where standard cable lengths of
six feet are used for convenience. All of the CEBAF 1458's are
interconnected with cables of approximately three feet (possibly less).
Three feet is the proper minimum length for RG-62 (90 Ohm) cables according
to the 1458 user's guide and other ARCNET interface reference material from
SMC.

We have recommended that Hall B try using six foot cables between mainframes
to see if this fixes the hangup problem.

The following is a list of facts which support to the theory that the
hangups are related to the cable lengths. These were realized after we had
completed our visit.
1) The monitor loop testing done on site (mentioned earlier) was at
the end of a six foot cable.
2) Hangups observed on 2/21 occured only after the mainframe closest
to the VME/ARCNET controller was connected onto the net. In this
configuration, the closet mainframe was connected onto the network with
cables of 3 feet (possibly less) between the controller and the next mainframe.
3) Prior to connecting the closest mainframe, the controller
to-next-node cable distance was approximately 6 feet when no failures were
observed.
4) Hall B personnel have since inter-connected their mainframes with
six foot cables and have yet to report any ARCNET hangups as previously
observed.

The manual for the SMC ARCNET controller card used in the 1458 has a number of
interconnection rules for various cable types. The minimum length for the
BNC bus configuration (used with the 1458) is listed as three feet.
Although on a later page in the same manual a six foot minimum length is
given for twisted pair cables. I am presently trying to contact SMC for
further clarification on the sensitivity to to cable distance between nodes.

To further support debugging, we requested that they create an active log of
the last 10 commands sent to a 1458 mainframe and that this log be dumped
when they observe any problems.

We also recommended that their standard ARCNET reset procedures include a
sequence of ARCNET receive commands to empty out any backup command
responses from a mainframe prior to sending additional commands.

Before we considered the cable length to be an issue. We suggested that they
check that their mainframes keep proper date and time since we have observed
some mainframe motherboards to lose their date/time after some period of
operation. (This is currently believed to be a hardware problem for some
motherboards.) The idea here was to correlate this date/time loss with an
ARCNET hangup.

Mike Green
Mike_G@pisun.lecroy.com
LRS Engineering
LeCroy Corporation (LCRY)