Steven and Robert:
Could I get a "full copy of the IOC" that Wayne mentioned? And could you include the configuration and motion program code(and any other code) for the controller as well?
Thanks.
Hi Wayne,
Thanks for the info. That fills in some of the gaps. Still some important details that I am hoping you (or someone) can help with.
What I (think) I know/understand so far (please correct me if I am missing something or have something wrong):
- As expected, I need to define a coordinate system (CS) on the controller and a motion program to trigger coordinated/synchronized movement for the affected motors. This requires that the motion program assign new values (as needed) to each axis in a single
command (as that is what triggers the synchronized movement of the affected motors)
- I tell the driver about the CS by calling pmacCreateCS(). This call includes the name for an asyn port to be created for the CS, the # for the CS I created on the controller, and the number of the motion control program to be run to trigger new motion
of the motors associated with the axes I defined in the CS.
- I tell the driver about the axes I defined in the CS by calling pmacCreateCSAxis() or pmacCreateCSAxes().
- I link a motor record to a CS axis rather than a motor by using the name of the asyn PORT for the CS (the one used in the pmacCreateCS() call) and the axis number for the ADDR (the # being the same as those used for calls to pmacCreateCSAxis(), which maps
the numbers 1-9 to some of the available axes as follows: 1-3 = A-C, 4-9 = U-Z).
- Writing to a motor record linked to a CS axis results in a write to a global variable (Q71-Q79). The readbacks for these records expect to find the latest readback values in another set of global variables (Q81-Q89).
- When executed, the motion control program for a CS reads the latest values for each axis in a CS from the global variables (Q71-Q79).
The main thing I am still missing is how you actually trigger a new coordinated move? I haven't found any function in the driver for this purpose. Is it triggered by writing to some asyn parameter in the driver? Do deferred moves have anything to do with
this?
Mark Davis , NSCL/FRIB
Control Systems Software Engineer
[email protected]
On 4/18/2019 8:04 PM, Wayne Lewis wrote:
Hi Mark,
You can interface the motor record directly to the PMAC-implemented
coordinate system axes using the DLS pmac module:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dls-2Dcontrols_pmac&d=DwIDAw&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=N5c9jjxdKJKM4FL5kzUqRKVlLFVSxrq-5uXTMd9aXwI&s=gaBMbu_Zw5cT9kXWue1vMO3nvrKexmPSWd7zMu59NLw&e=
A few things to include in your IOC to make use of this:
In <ioc>App/src/Makefile:
<yourioc>_DBD += drvAsynPowerPMACPort.dbd
<yourioc>_DBD += pmacAsynIPPort.dbd
<yourioc>_DBD += pmacAsynMotorPort.dbd
<yourioc>_LIBS += pmacAsynIPPort
<yourioc>_LIBS += pmacAsynMotorPort
<yourioc>_LIBS += powerPmacAsynPort
In iocBoot/ioc<yourioc>/st.cmd:
epicsEnvSet("PPMAC_IP", "192.168.0.201")
epicsEnvSet("PPMAC_SSH_PORT", "PPMAC_SSH")
epicsEnvSet("PPMAC_PORT", "PPMAC1")
epicsEnvSet("PPMAC_CS2_PORT", "CS2")
# Attach to the SSH port
#drvAsynPowerPMACPortConfigure(port_name, host_address, username, password, priority, noAutoConnect, noProcessEos)
drvAsynPowerPMACPortConfigure("$(PPMAC_SSH_PORT)", "$(PPMAC_IP)", "root", "deltatau", 0, 0, 0)
# Configure Model 3 controller driver
# powerPmacCreateController(controller_port, low_level_port, address, axes, moving_poll, idle_poll)
pmacCreateController("$(PPMAC_PORT)", "$(PPMAC_SSH_PORT)", 0 , 32, 100, 200)
# Create the Model 3 motion axis drivers
#pmacCreateAxes(controller_port, axis_count)
pmacCreateAxes("$(PPMAC_PORT)", 7)
# Set up for running coordinate system
#pmacCreateCS(coordinate_system_port, controller_port_name, coordinate_system_number, motion_program_number)
pmacCreateCS("$(PPMAC_CS2_PORT)", "$(PPMAC_PORT)", 2, 2)
# Create the coordinate system axes
#pmacCreateCSAxes(coordinate_system_port, num_coordinate_system_axes)
pmacCreateCSAxes("$(PPMAC_CS2_PORT)", 9)
# Define coordinate step resolution
#pmacSetCoordStepsPerUnit(coordinate_system_port, cs_axis, counts_per_egu)
pmacSetCoordStepsPerUnit("$(PPMAC_CS2_PORT)", 8, 1000000)
Then in your motor record substitutions file, you can define both the
physical motors and the virtual motors, with the only necessary
difference being the asyn port that they talk to. The physical motors
use the port created in the pmacCreateController() function in the
st.cmd file. The virtual motors use the port created in pmacCreateCS().
file $(MOTOR)/db/basic_asyn_motor.db {
pattern {P, M, DESC, DTYP, DIR, VELO, VBAS, ACCL, BDST, BVEL, BACC, PORT, ADDR, TIMEOUT, MRES, PREC, EGU, DHLM, DLLM, INIT }
# Physical motor (using PPMAC1 port)
{ $(P),"Mtr", "Stepper motor counts", asynMotor, 0, 0.5, 0.0, 1.0, 0.0, 0.0, 0.0, PPMAC1, 1, 1.0, 0.0002, 3, mm, 0.0, -26.0, 0 }
# Coordinate system motor (using CS2 port)
{ $(P),"CSGap", "CS Gap", asynMotor, 0, 0.5, 0.0, 1.0, 0.0, 0.0, 0.0, CS2, 8, 1.0, 0.000001, 3, mm, 0.0, 0.0, 0 }
}
A few other points:
The Diamond PMAC driver has a defined interface for the coordinate
system motor positions and setpoints. Q71-79 for the setpoints, Q81-89
for the position reporting readbacks.
You will want to write a position reporting PLC the implements the
forward kinematics to provide continuous readback updates for the motor
record RBV field. This was definitely a requirement for the Turbo PMAC;
the Power PMAC documentation no longer refers to it, but I haven't found
a way to get continous updates from the coordinate system forward
kinematics. Maybe someone else out there can help more here.
You could contact the LBNL people copied on this email to get a full
copy of the IOC.
Some answers to your other questions:
And even then, doesn't there need to be some supporting logic running on
the controller? As near as I can tell, coordinated motion on the Power
Brick controller requires a motion program running on the controller,
however trivial a program it may be.
If you want to use the PMAC coordinated motion, you need to define the
kinematics (either via forward and inverse kinematics or through the
equation-based definition) and provide a motion program. PMAC coordinate
systems must run through a motion program.
Hope that helps.
Wayne
On Thu, Apr 18, 2019 at 02:50:32PM +0000, Davis, Mark via Tech-talk wrote:
Hi all,
We will soon be adding a couple of motors to a Delta Tau Power Brick
controller that will control the left and right drives for a slit and I
was hoping someone could provide me some direction about how to go about
using the Model 3 motor interface to achieve coordinated motion control
of the two drives on the controller itself.
From what I learned from the Delta Tau online training videos I was
able to use the vendor's PowerPMAC IDE to define a coordinate system
with the two motors and two axes (one for center position and one for
the gap), define the relationship between the motor's positions and the
two axes, and write a trivial motion program that causes the two motors
to move correctly in response to a change to the setpoint for the two axes.
But that is as far as I have gotten. Ignoring for the moment everything
but the most basic aspects of this, what I need is to have two records,
one for the center position and one for the gap, and to have changes to
one or both of these to cause the two motors to move as needed to
satisfy the new settings. I currently have such a setup where all the
coordination of the motion is done in EPICS record logic (using the
separate motor records for each drive), but we want to eliminate all
that and have the controller coordinate the motion of the motors.
As I understand it, one of the basic advantages of the Model 3 interface
for motors is that it includes support for such coordinated motion.
And, from what little I have learned so far, it requires you to supply
the interface with a list of the motor movements that the controller
should execute.
Is this correct? And if I want to avoid going around the Model 3
interface, is this the only way to get coordinated motion that is
managed by the controller?
If so, this would still seem to require some significant record logic
(and possibly supporting code) to go from a change in the center and/or
gap setting to generate and set the values in the necessary data
structures and call the appropriate functions in the interface.
And even then, doesn't there need to be some supporting logic running on
the controller? As near as I can tell, coordinated motion on the Power
Brick controller requires a motion program running on the controller,
however trivial a program it may be.
If someone could outline the whole process and what is needed to go from
the center and gap setpoint records to invoking the motion on the
controller, that would be a major help and save me loads of time and effort.
-------
Mark Davis
NSCL/FRIB Control Systems Software Engineer
[email protected]
|