Subject: |
Re: MAXv model-3 - error reading axis position after 5 attempts |
From: |
Benjamin Franksen <[email protected]> |
To: |
<[email protected]> |
Date: |
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µ
Wed Oct 30 17:01:45 CET 2013 [email protected]
* set the RA_DONE flag when motor_motion is reset to NULL before callback is issued
This fixes a long-standing issue with OMS boards where occasionally the
motor record hangs after a move against a limit switch, since it reads a
wrong status where the RA_DONE flags is not set.
diff -rN -u old-motor_6.8/motorApp/MotorSrc/motordrvCom.cc new-motor_6.8/motorApp/MotorSrc/motordrvCom.cc
--- old-motor_6.8/motorApp/MotorSrc/motordrvCom.cc 2014-01-14 15:41:17.000000000 +0100
+++ new-motor_6.8/motorApp/MotorSrc/motordrvCom.cc 2014-01-14 15:41:17.000000000 +0100
@@ -276,6 +276,7 @@
motor_free(motor_motion, tabptr);
motor_motion = (struct mess_node *) NULL;
motor_info->motor_motion = (struct mess_node *) NULL;
+ mess_ret->status.Bits.RA_DONE = 1;
}
callbackRequest(&mess_ret->callback);
Attachment:
signature.asc
Description: This is a digitally signed message part.
- References:
- MAXv model-3 - error reading axis position after 5 attempts Luchini, Kristi L.
- Navigate by Date:
- Prev:
RE: MAXv model-3 driver - omsMAXvConfig problem D'Ewart, J. Mitch
- Next:
Re: Using a Waveform record (char type representing a String) as input to an aSub record Benjamin Franksen
- 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: MAXv model-3 - error reading axis position after 5 attempts Jens . Eden
- Next:
MAXv model-3 driver - omsMAXvConfig problem Luchini, Kristi L.
- 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
|