Experimental Physics and
Industrial Control System

• A generic way for an application/driver/etc to define how a group of motors need to move (in unison) to achieve the desired coordinated motion (the sequence of PVT movement commands)
  
• Controller-specific driver logic that translates and forwards the sequence of movement commands to the controller and then triggers the sequence of movements.
• The controller itself processes the sequence of movement commands, so the overall motion is (or at least COULD be) much smoother than if it was given just one step of the sequence at a time, and (as long as no errors occur) the position and speed of each motor is always correct (i.e. no motor gets ahead or falls behind during any movement).
• If any problem occurs, it is handled in a safe manor by the controller (something that may require application-specific code running on the controller, since something generic such as simply stopping all the motors may NOT be an appropriate or safe response in many cases)
  
• Elimination of the overhead of having the IOC trigger each step separately and verifying its completion before triggering the next step.

Hi Mark,

I am not an expert on the Delta Tau.  However, my understanding is that if you define a coordinate system inside the controller, that will expose new "virtual axes" that you control with normal EPICS motor records.  You don't need to use the coordinated motion API of the model 3 driver at all.  I am not sure how you connect a motor record to one of the new axes that you have created with your motion program, but hopefully someone with more Delta Tau experience will chime in.

For the Delta Tau the Model 3 coordinated motion API can be used when you do NOT define a coordinate system inside the controller, but rather you stream a series of PVT move commands to the controller.  This is used for more complex coordinated motion where it would be hard to define the logic inside the controller, for example a 6-circle diffractometer where the geometry code is already running in an external application.

Mark


-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Davis, Mark via Tech-talk
Sent: Thursday, April 18, 2019 9:51 AM
To: [email protected]
Subject: Coordinated motion of slits

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]