At Jefferson Lab there are several MVME 167/177 IOCs with OMS VME44
stepper motor control cards. When they are combined with an MVME 162
card running HiDEOS in the same crate, we have been experiencing ioc
crashes. These may occur after several motor moves, or they may never
occur, depending on the particular combination of software applications,
OMS card and stepper motor chassis, the latter being used to supply
power to the motor and to microstep. When the ioc crashes, it locks
up immediately after a step is given, and there is no way to log on to
determine the problem.
A great deal of time has been spent trying to debug this annoying
problem. The following is a summary of findings:
1. The problem did not occur on a test ioc when there were
no other applications present. However, when an IP Digital48
I/O card was added along with an application which used scan
tasks on this card, we got consistent crashes (no crashes when
the scans were changed to passive). We had been using the epics
steppermotor record, but for debug purposes switched to a very
short subroutine record which talked directly to the OMS card.
This appeared to very consistently eliminate the problem, so
we thought there was a bug in the steppermotor record.
2. When we moved the working applications to an operational ioc,
the problem resurrected, even with the simple direct OMS card
addressing subroutine. It occurred with or without the
steppermotors connected to the chassis, which ruled out the
motor itself. In contrast, similar setups on 2 nearby operational
iocs, using epics steppermotor records, along with Digital48
scan task applications work extremely reliably. When questioned,
the developer of these systems said she spent many weeks working
with the hardware people to find the right combination of chassis
and OMS cards that worked.
3. Further testing of the non-reliable system on the operational
ioc showed that the system could be made to work fairly reliably
by setting ECHO OFF. The default option is ECHO ON and this is
set in the steppermotor record. When it was set OFF in the
subroutine record version, 4 of the 5 motors appeared to work
reliably, and have been so operating for several months. Setting
ECHO OFF appears to reduce bus traffic and hence the probability
of conflict with HiDEOS tasks and/or the fair amount of noise
which was present on the bus. However, the fifth motor continued
to cause crashes after a random number(generally 1- 20) of steps
were given. This problem was greatly and consistently reduced
by removing an application on the ioc which used GPIB 1 second scan
tasks. Removing another GPIB application on the ioc with only
passive scans made no difference. The system is now running with
only the Digital48 and passive GPIB tasks, but still crashes on
occasion, after perhaps several hundred steps. We are int he process
of removing all HiDEOS tasks from this ioc.
4. Another system, developed independently by a third person at
the lab, and using the epics steppermotor record, also experienced
periodic crashes when running on an operational ioc with other
applications, several of which used HiDEOS. When this system was
moved to a spare ioc with no other applications, the crashes ceased.
Has anyone else experienced such problems with the OMS VM44 ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Al Grippo
Jefferson Laboratory
Newport News, VA
757-269-5015
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
- Navigate by Date:
- Prev:
Advice sought on fanning data to several PVs Ron Chestnut
- Next:
RE: OMS steppermotor problem Mark Rivers
- Index:
1994
1995
1996
1997
<1998>
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Advice sought on fanning data to several PVs Tim Mooney
- Next:
RE: OMS steppermotor problem Mark Rivers
- Index:
1994
1995
1996
1997
<1998>
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|