> 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
- References:
- MAXv issue Dirk Zimoch
- RE: MAXv issue austen.rose
- Re: MAXv issue Dirk Zimoch
- RE: MAXv issue austen.rose
- Navigate by Date:
- Prev:
RE: MAXv issue Davidsaver, Michael
- Next:
RE: ca_put_callback once again Jeff Hill
- 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 issue Davidsaver, Michael
- Next:
Re: MAXv issue Jens . Eden
- 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
|