I have also seen that the ACS steppers introduce a _lot_ of noise in to
the limit lines, at NSLS we used a transition card of similar ( maby the
same ) design to reduce the problem. We had not seen the same behavior
with any other driver/amplifier system that I am aware of.
There is another failure mode on the VME58 that is worth mentioning
in this thread.
The vme bus reset on the oms8/58 is very sensitive, we have see
under high noise conditions, and cases of static discharges that the
OMS cards will reset while the system controller will not leaving the DB
and the hardware out of sync. This gives rise to a very annoying and
time consuming errors, and the possibility of equipment damage where
administrative/soft limits are used. Proper grounding and shielding
should prevent this, but we have see that some of our older painted vme
chassis were sensitive despite this.
Again here the maxv uses a newer reset system and should not be
sensitive.
Bill Nolan
Washington University Medical School
Department of Biochemistry
4566 Scott Ave.
Mail Stop 8231
St. Louis, Mo 63110
1.314.362.4445 Fax 1.314.362.7183
Mark Rivers wrote:
> The transition cards that the APS BCDA group built to connect the
> OMS58/MAXv and the ACS Step-Pak drivers have on-board de-glitching
> capacitors. These increase the time constant on the limit switch lines
> so that we never see problems, even with very long lines from the
> controller to the driver.
>
> This is generally a simple and cheap solution.
>
> Mark
>
>
>
>> -----Original Message-----
>> From: Ronald L. Sluiter [mailto:[email protected]]
>> Sent: Monday, November 13, 2006 2:15 PM
>> To: Emmanuel Mayssat
>> Cc: EPICS
>> Subject: Re: Motion control failure at APS
>>
>> The OMS VME58 is susceptible to noise on the limit switch lines.
>> This has been the most frequent problem that I have been called on
>> the diagnose.
>>
>> Kurt Goetze and I did some testing to see if this is a
>> problem with the
>> MAXv. Of course we can't quantify it, but it appears that OMS has
>> done a much better job with the MAXv on this issue.
>>
>> Ron
>>
>> Emmanuel Mayssat wrote:
>>
>>
>>> I actually had the exact opposite problem.
>>> My motor controller would barely start a move.
>>> The limit switches were reported as not closed, and the
>>>
>> apparatus was in
>>
>>> a safe position to operate. The problem was due to glitches
>>>
>> on the limit
>>
>>> switch cables (we actually never observed those glitches).
>>>
>> The problem
>>
>>> was reproducible in a controlled environment (engineering bench).
>>> As of today, we think it was due to cable length and cross talking.
>>> We rebuild and shortened the cables. It immediately worked.
>>>
>>> Food for thoughts and... time for lunch,
>>>
>>> --
>>> Emmanuel
>>>
>>> On Mon, 2006-11-13 at 12:56 -0600, Mark Rivers wrote:
>>>
>>>
>>>
>>>> Folks,
>>>>
>>>> We have seen failures in the past where a motor moved
>>>>
>> constantly at a
>>
>>>> slow rate right past limit switches on an OMS58. It
>>>>
>> happened only on a
>>
>>>> single axis, not on all 8 axes.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
- References:
- RE: Motion control failure at APS Mark Rivers
- Navigate by Date:
- Prev:
Re: devSNMP: Thread error? Andrew Johnson
- Next:
RE: devSNMP: Thread error? Kagarmanov, Albert
- 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: Motion control failure at APS Kurt Goetze
- Next:
RE: Motion control failure at APS Reinhard Pahl
- 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
|