Experimental Physics and
Industrial Control System

Wayne Lewis via Tech-talk <[email protected]> · Thu, 18 Apr 2019 17:04:47 -0700

Hi Mark,

You can interface the motor record directly to the PMAC-implemented
coordinate system axes using the DLS pmac module:

https://github.com/dls-controls/pmac

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]

-- 
  Wayne Lewis
  e: [email protected]
  w: http://ospreydcs.com
  p: +1 631 905 1964

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System