Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Tue, 23 Nov 2010 10:01:57 -0600

> 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?

No, the sscan record does not poll on DMOV, it uses ca_put_callback.
The motor record only fires its forward link when the move, including
backlash correction, etc. is complete.

Mark

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, November 23, 2010 8: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