Re: APS stepmotor pinout st

['Dan Legnini' <dan_legnini@qmgate.anl.gov>]

                      RE>>APS stepmotor pinout sta                 11/12/96

>From: Mark S. Engbretson
>For what it is worth . . . BESSRC has been getting a lot of >pre-wired
motorized devices in which  claim correspond to some >'APS Motor direction
Standard' - i.e. clockwise or some such.

>However, the manufacturers in their infinite wisdom have not been >taking the
time to insure that whatever direction they choose as >clockwise are actually
matching what the limits switchs expect as >clockwise - whichimplies that we
re-wire limit switches about 50% >of the time. 

we have had the same experience.  i have brought this to the attention of juan
barraza, the enginneer who works on many of the  standard components, who was
unaware of the problem.  he said he would check with the vendors.

>IMHBBO, I could care less what the 'raw' direction a motor >actually moves in
. . . after going through gear reduction and >limitation on where they can
mount the thing, a default >'direction' isn't going to mean a ****** thing
anyway. 

as outlined in the introduction section of the web docs, there are a couple of
principles which drive this standard:
the raw wiring should be the same for all motors of a given type, the raw
wiring should be as consistent as possible for different products from the
same vendor, 
the raw direction should be the same for a given low-level command from the
control system for different motors from the same or different vendors,
all of the above is regardless of how they are geared or what is moving.  

if these 'rules' are adhered to, this allows motors to be replaced or
borrowed, for simplified communications with technicians (or vendors, see
above), and facilitiates checking to see if it is 'right'.  
btw:
the re-wiring problem with APS tables discussed above has as much to do with
sloppy assembly/QA as it to does with the gearing being different on different
axes.  check your limit switches early in commissioning!

>In a perfect world, the default direction would always be in the >'natural'
coordinate system that a device, say a table normally >moves. 

i believe this falls into the realm of user-specified parameters, which vary
from device to device, and sometimes from user to user even for the same
device.  the standard only hints that we may want to approach this part of the
problem from the same philisophical point of view, but doesn't try to
'standardize' at this level.  

if we were to agree on a philosphy, then software implementation of complex
devices might be able to share pieces of support code, and users might be able
to move from beamline to beamline with less stress, even if the control system
is not the same at the hardware level or even were to use different software
tools.

i think i'm dreaming...

--dan