Experimental Physics and
Industrial Control System

[email protected] (Hubert Yamada) · Fri, 23 May 1997 10:38:38 -1000

Your problem sounds very similar to problems that I have been having
with the steppermotor oms driver this week.

I found that the record worked very reliably when I was running two
mechanisms.  Unfortunately, I have just added 12 simulated mechanisms,
and Steven Beard has added support for the CICS to my system.  I
suddenly find that if I am simultaneously finding the home position for
all the real mechanisms and simulated mechanisms, then the first move
commands after setting home fails (intermittantly) to move the
hardware.  If it does fail, it leaves the record in a state in which
the record's internal position counter does not match the OMS hardware
counter.  If I move only one mechanism at a time, it always works
reliably.  Also, if I don't load the CICS databases / snl code, it
works reliably for all mechanisms.  This has been very frustrating,
because it happens much more frequently immediately after rebooting the
system, which is a rather time-consuming problem.  It also seems to
happen in bunches.  It will work perfectly for a few hours, and
I will think that I found the problem, and then it will return again.

At this point, it is worth the trouble for me to spend a little more of
my time trying to figure out why the record is failing, but if I can't
isolate the problem in a reasonable amount of time, I intend to try the
motor record instead.

Note:  Originally, I found that the steppermotor record would not drive
even one mechanism reliably.  It would report that it had finished
moving, and the step counter would stop incrementing, but the hardware
would continue to turn.  I traced that to a timing problem in the oms
support, which is caused by the faster real-time clock on the Gemini
systems.  This was easily worked around, by changing a taskDelay(2) in
the oms driver to a taskDelay(10).  However, the problem vanished the
last time that I upgraded my version of EPICS; my previous version had
been built in a rather non-standard way, because of compiler licensing
problems, so I assumed that it was simply a problem with my system.

It may be worth editing your copy of drvOms.c, changing taskDelay(2) to
taskDelay(10).  One cost of this is that the DMOV field does take a
little longer to toggle, which makes it very hard to determine exactly
when the hardware starts moving.  This is not a problem for most
applications, but does cause some problems for my interface to the
A&G system, which wants very precise timings.

Hubert

-- 
Hubert Yamada, University of Hawaii, Institute for Astronomy
 phone: (808) 956-6648                 
e-mail: [email protected]
   WWW: http://ccd.ifa.hawaii.edu/~yamada/

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System