Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Tue, 23 Nov 2010 10:55:50 -0500

Out of curiosity has anyone seeing this problem captured/archived the
RRBV or RVAL fields?  I am curious if this is related to a problem Daron
and I were seeing last summer.

http://www.aps.anl.gov/epics/tech-talk/2010/msg00911.php

The problem was corruption during VME reads resulting in extra bits
being set in the top word.  So 0x00000134 would become 0xffff0134.  This
was causing crashes because the driver was using 32-bit reads for 16-bit
registers and not checking.  We put in a patch to switch to 16-bit reads
and the crashes have gone away, but the problem is still occurring.

This is significant because both the motor position and encoder
registers are legitimately 32-bit.  If a corrupt value is read it could
cause further moves if feedback is used.  This isn't a problem for us
because the system has no encoders, and we have disabled the motor
record's retry function.

Is anyone affected seeing the "drvMAXv.cc:motorIsr: command error" error
message?

Michael

> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of [email protected]
> Sent: Tuesday, November 23, 2010 9:47 AM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: MAXv issue
> 
> Hi Dirk,
> 
> At first sight this would suggest a problem with the MAXv firmware,
but
> I've not experienced this. I rarely capture the raw motion commands
> sent
> to the controller. It does sound odd, as I am sure that we would have
> experienced this kind of failure at Diamond by now as we have a fair
> number of cards deployed.
> 
> We have had two problems with our last batch of cards. One did not
have
> its factory default settings restored before it arrived and the other
> had a solder issue on one pin of one of the backplane connectors.
> 
> Do you ever see "tdir=0" (or 1) at the same time as control is lost?
> Have you run any debug on the motor record?
> 
> I have not used the sscan record so I cannot comment on its
interaction
> with the motor record. I assume it uses DMOV to determine the end of
> one
> move?
> 
> Regards,
> 
> A.
> 
> 
> 
> -----Original Message-----
> From: Dirk Zimoch [mailto:[email protected]]
> Sent: 23 November 2010 11:10
> To: Rose, Austen (DLSLtd,RAL,DIA)
> Cc: [email protected]
> Subject: Re: MAXv issue
> 
> Hi Austen,
> 
> What I actually see is that at a normal move the motor runs in the
> wrong
> 
> direction. The retry then corrects this provided the limit switch is
> not
> 
> hit.
> 
> The IOC sends: "AT  VB1250 VL5000 AC7500 AF  MR-162 GD ID"
> 
> Then when polling the status with "AT QA EA", the MAXV replies
> "PNNN,DDNNN", clearly announcing that is runs in POSITIVE direction
> even
> 
> though it has been commanded to run -162 steps..
> 
> We use the sscan record to do the scan. The MAX is used with internal
> encoder feedback.
> 
> Dirk
> 
> 
> [email protected] wrote:
> > Hi Dirk,
> >
> > I have seen a similar problem, although not quite the same.
> >
> > To get a higher update rate into the archiver I did the following
> > (MVME5500 processor running vxWorks):
> > 1/ sysClkRateSet(1000)
> > 2/ MAXvSetup(1, 16, 0xF000, IVEC, 5, 60)
> > In the cmd file, and this gives me 60 Hz data.
> >
> > However, when running in this configuration I get an unrequested
move
> > following a successful move that has a retry. This unrequested move
> then
> > takes it off to "infinity".
> >
> >
> >
> >
> > Are you seeing the problem following (and only following) a retry?
> >
> >
> > Regards,
> >
> > Austen Rose.
> >
> >
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Dirk Zimoch
> > Sent: 23 November 2010 10:10
> > To: EPICS
> > Subject: MAXv issue
> >
> > Hi MAXv users,
> >
> > We see a problem here with our MAXv cards and I want to ask if
anyone
> > has seen the same effect. This could help us to understand what's
> > happening.
> >
> > During a long series of scans that drives a motors in negative
> direction
> >
> > in pretty small steps, it happens in rare cases that the motor
> instead
> 
> > runs forward a quite large amount, possibly hitting the limit
switch.
> >
> > We have observed this behavior a few times in intervals of some
three
> > hours. Then again nothing went wrong for days. The problem happened
> with
> >
> > two different axes and on several different MAXv cards (including
> cards
> > with and without the latest bug fix -> see Ron Sluiter's mail "OMS
> MAXv
> > announces fix" from October 27)
> >
> > Pro-Dex is informed but they would like to have more input on the
> > specific circumstances. Thus my question: Has anyone seen a similar
> > effect? Under which circumstances did it happen?
> >
> > Dirk
> >
> 
> 
> --
> This e-mail and any attachments may contain confidential, copyright
and
> or privileged material, and are for the use of the intended addressee
> only. If you are not the intended addressee or an authorised recipient
> of the addressee please notify us of receipt by returning the e-mail
> and do not use, copy, retain, distribute or disclose the information
in
> or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual
> and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> attachments are free from viruses and we cannot accept liability for
> any damage which you may sustain as a result of software viruses which
> may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in
> England and Wales with its registered office at Diamond House, Harwell
> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
> Kingdom
> 
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System