[Date Prev][Date Next][Date Index]
Re: Reply to Ben Ocko re: pseudomotors
Mark Rivers wrote:
> I am completely convinced that what you propose is the
> right way to do it. We need to make an EPICS pseudomotor
> record which has all of the same fields as the EPICS motor
> record.
I don't think an EPICS pseudomotor record needs to have all the
same fields as the EPICS motor record. The EPICS motor
record is pretty complex and requiring pseudomotor
records to deal with that complexity will probably slow
down any implementation. I'd say minimum capabilities
need only include:
start (move to a position)
read (read current position)
get status (busy/ready/fault/...)
stop (abort move)
Other _optional_ capabilities could include:
set position (set/calibrate current position to a value)
set speed
set acceleration
Certainly there are others, but there is no need to get
bogged down in dealing with all possibilities. As far as
spec is concerned, unique features of particular
pseudomotors could be dealt with using spec's generic
channel access functions epics_get() and epics_put().
My intention in spec would be to use a different motor type
for EPICS pseudomotors and just insist that the minimum
capabilities exist. A set of optional capabilities
could be probed for by seeing if the process variables
existed, but the absence of any capability would not be
fatal.
Another issue of standardization concerns naming of the
pseudomotor channels. Spec uses what seems to be the
convention for naming EPICS motors, in that process
variable names are formed from a 'prefix' plus the letter
'm' plus an integer starting from 1. The 'prefix' can be
any string. In the spec configuration file, each motor is
given a unit and a channel number. The unit number is
associated with a particular prefix. The channel number
can be any integer.
If the naming of EPICS standard pseudomotors requires
greater flexibility, it would be possible in spec (as is
done for the 13-character XIA Huber slit controller
serial numbers) to have a more lengthy motor name entered
as a 'generic parameter' on the spec optional-parameter
motor screen. That is not any trouble to program, but does
add to the configuration burden of the spec site
administrator. A standard naming/numbering
convention for pseudomotors would be helpful.
Anyway, I too, have been pleading for such a
standardization for years, but have been told that
nobody would want to do it, so I have been unable to
implement EPICS pseudomotors directly in spec.
Gerry Swislow
phone: (617) 576-1610
Certified Scientific Software fax: (617) 497-4242
PO Box 390640 email: gerry@certif.com
Cambridge, MA 02139-0007 Web: http://www.certif.com
--------------
Begin forwarded message:
> Date: Sat, 23 Jan 1999 10:35:37 -0600
> From: Mark Rivers <cars3.uchicago.edu!RIVERS@photon.mit.edu>
> To: APS.ANL.GOV!BEAMLINE_CONTROLS@photon.mit.edu
> Cc: cars3.uchicago.edu!RIVERS@photon.mit.edu
> Subject: Reply to Ben Ocko re: pseudomotors
>
> From: CARS3::RIVERS 'Mark Rivers' 23-JAN-1999 10:33:50.53
> To: SMTP%'benocko@pouch.com'
> CC: RIVERS
> Subj: RE: EPICS/psuedomotors
>
>
> Hi Ben,
>
> > I would like to solicit your advice about EPICS. My limited
> > understanding is that you can write EPICS code to create a psuedo motor
> > that will drive more than one actual motor using a user defined
> > function. Whereas there is a standard EPICS subroutine call to move a
> > normal motor, there is no such call for these psuedo motors. If this
> > were the case, one could use the standard SPEC scans without further
> > modifications. This is important, for instance, if you want to move a 3
> > legged table up and down and you only care about the height and not the
> > level. Other psuedo motors might
> > adjust the level keeping the height the same. the level.
>
> You are pretty much correct. It is not a subroutine call,
> but rather an EPICS motor record, which you can think of as
> an 'object' in the programming sense. The motor record
> has standard fields (or properties) like DVAL (the drive
> position in dial units), DRBV (the drive readback in dial
> units), DMOV (a flag which says if the motor is done
> moving), etc. EPICS moves individual motors with this
> record. The problem is that compound motors (the height
> of a lift table) have not been done in a standard way. There
> is a 'table record' which Tim Mooney wrote which lets you
> drive a lift table, but it does not have the same field
> names as a standard motor. Because it is a single record it
> cannot have the same field names, since there would need
> to be multiple DVAL fields, for example, and there can
> only be one field of a given name per record.
>
> When we use the standard EPICS scanning tools this is not
> really a problem, because I can tell it to scan any EPICS
> field, wait for any other EPICS field before proceeding,
> etc. However, SPEC only knows how to drive the EPICS motor
> record, not any arbitrary EPICS field (though you can do
> that with SPEC macros).
>
> I am completely convinced that what you propose is the
> right way to do it. We need to make an EPICS pseudomotor
> record which has all of the same fields as the EPICS motor
> record. The pseudomotor record would actually do very
> little. It would check soft limits and do a few other
> things. The actual work would be done using an EPICS State
> Notation Language program in the VME crate which detects
> commands to move pseudomotors and moves the real motors,
> reads back the positions of the real motors and computes
> the positions of the pseudomotors. I have already done
> something similar in EPICS for 2 applications:
> - A general purpose 2-D coordinate transformation. Given one X-Y
> coordinate system, you can move pseudomotors in another coordinate system
> which is translated and rotated with respect to the first.
> - A pseudo 2-theta arm, which is made of an X-Y-theta stages. One can
> drive this device with the pseudomotors Radius and Theta.
> The problem with my system is that since there is no
> pseudomotor record I had to do this with a collection of
> standard EPICS records (like analog out and binary out).
> Thus, the field names are not the same as the motor record
> and SPEC can't drive them.
>
> I am hoping that Ron Sluiter and Tim Mooney will do this,
> and I have heard rumors that they are. It should not be too
> difficult, and I and others have been asking for it for a
> long time. If it does not happen soon I will do it myself
> when I can.
>
> Cheers,
> Mark
>