Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 12 Mar 2014 00:18:59 +0100

Hi Kristi

this may be related or not: A few months ago we fixed a bug in R6-8 of the
motor module that caused us problems with OMS cards. See the message quoted
below and the attached patch for details. I never got a response from Ron
Sluiter, so maybe the message got lost somehow. What prompts me to send this
is that the bug we experienced was timing related, too. Also, the bug is in
motorApp/MotorSrc/motordrvCom.cc, a module that is apparently not specific to
OMS cards...

Cheers
Ben

----------  Weitergeleitete Nachricht  ----------

Betreff: A patch for the EPICS motor module
Datum: Dienstag, 14. Januar 2014, 16:03:41
Von: Benjamin Franksen <[email protected]>
An: [email protected]

Hi Ron

you may be aware that for a long time we had a problem when using the
motor module together with OMS cards. Specifically, the motor record
sometimes "hangs" after a move against a limit switch (it recovers when
receiving a new Stop or Go command). Bernhard Kuner told me that you
could not reproduce the problem. We found that the problem only
manifests itself if the speed of the CPU board is slow relative to the
motor card/driver. With the old mv162 the error was easily reproducible,
while with a mv2100 it occurred only rarely. The CPU cards you use for
testing are probably much faster than our ancient mv162, which would
explain that you could not reproduce this.

Anyway, after some intensive debugging we actually found the cause of
the problem. The fix is very simple (one line of code in file
motorApp/MotorSrc/motordrvCom.cc), see the attached patch file. We took
some time to test this change in our production system and found that
now everything runs smoothly. BTW, the change in the patch is against
version R6-8 of the motor module.

Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
-------------------------------------------------------------

Am Donnerstag, 6. März 2014, 15:29:19 schrieb Luchini, Kristi L.:
> Hello,
>
> Has anyone seen this error on the new model-3 version of the MAXv driver
> (omsAsyn) ?
>
>    8544 omsBaseDriver:BasePoller:MAXv-01: error reading axis position after
> 5 attempts^M 8545 omsBaseDriver:BasePoller:MAXv-01: error reading axis
> position after 5 attempts^M 8546 omsBaseDriver:getAxesArray:MAXv-01: array
> string conversion error, count: 0, axes: 8, input:
> >MNNN,PNNN,MNNN,PNLN,PNLN,PNLN,PNLN,PNLN<^M 8547 2014/02/05 12:03:30.540
> omsBaseDriver:readInt32:MAXv-01 wrong AUX state N^M 8548 2014/02/05
> 12:03:30.670omsBaseDriver:getAxesArray:MAXv-01: array string conversion
> error, count: 0, axes: 8, input:
> >MNNN,PNNN,MNNN,PNLN,PNLN,PNLN,PNLN,PNLN<^M
>
> We have seen this error in  a few motion control applications with MAXv
> controllers.  All of the IOCs were running motor-R6-8 asyn MAXv driver.
> The problem seems to occur when we're using a number of axis, and in some
> cases using virtual motors where multiple axis are moved at once.
>
> 1) MAXv  controller, with 2 steppers and 1 servo motors. This  MAXv has FW
> 1.45 2) MAXv controller , with 8 steppers. This MAXv has FW 1.44 (vitual
> motors moving 4-axis at once, and 2-axis at once using transform record) 3)
> MAXv controller, with 7 steppers.  This  MAXv has FW 1.31  (virtual motors,
> moves 4 axis at once, and 2-axis using transform record)
>
>
> Mitch D'Ewart found that  "The omsMAXv::sendOnly function checks the input
> buffer and flushes one response if there is anything there but we seem to
> have come on a case where there are multiple responses backed up.  These
> responses are controlled by a message semaphore.  It seems that once
> sendOnly flushes the input buffer and clears the semaphore then the MAXv
> sends another backed up message response.  Finally the receive part of the
> calling function gets the wrong message.
>
> There are two solutions that have been implemented recently at SLAC. Both
> will be booted on Monday 3/10/2014, in production. So we don't know if the
> problem is fixed yet.
> 1) Ziga added eieio in omsMAXv.cpp by including basicIoOps.h from Till
> Strauman.
>
> Example:
> static void writeReg8(volatile epicsUInt8 *a8, epicsUInt8 value)
> {
> #ifdef HAS_IOOPS_H
>     out_8(a8, value);
> #else
>     *a8 = value;
> #endif
> }
>
> 2) Mitch, changed the function sendOnly() to flush multiple responses.
>
> Details:
> Motor-R6-8
> Asyn-R4-12
> EPICS R3.14.12
> RTEMS-4.9.4
> MVME6100 CPU.
> MAXV-8000
>
> QUESTION:
> How shold asyn support implementation  respond in this sort of case, where
> the response messages get out of sync with the queries? Do you simply clear
> you the response buffer, buffer and start again, or is there another
> solution?  Has anyone else implemented a fix to this Particular MAxv but or
> to another asyn support driver?
>
> Regards,
>   Kristi

--
Perl: There Is More Than One Way To Do It
Python: There Is One Way To Do It
Haskell: There Is One Way To Do It, Up To Isomorphisµ

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System