Re: Coordinated motion of slits

["Davis, Mark via Tech-talk" <tech-talk@aps.anl.gov>]

Hi Mark,

In terms of my current project (the slit drives), it looks like the response from Wayne provides a good starting point.  NO doubt I will have more detailed questions for him (or whoever else  is sufficiently familiar with the PowerPMAC driver) once I dig in to that a bit more.

Regarding the API in the Model 3 interface vs coordinated motion, I am rather confused.

I have been assuming that the key advantages of the coordinated motion API in the Model 3 motor interface included the following:

• 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.

I seem to recall seeing something in one of the Power Point presentations regarding the Model 3 motor interface that stated that using it rather than more traditional methods (e.g. nested sscan records) resulted in a major decrease in scan times.  I assumed this was because the controller was running, if not the entire scan, then at least significant size pieces of it on its own.  But maybe it was simply moving it all into a single layer on the IOC that resulted in so much improvement?

For the Delta Tau Power Brick (and presumably any of the Power PMAC controllers), the only way I know of to insure well coordinated motion of multiple motors is to define a coordinate system and execute a motion program that updates the values for the defined axes, computes new motions for each motor affected, and triggers the coordinated movement of all the affected motors. Whether this is done one movement command at a time or for a sequence doesn't change this (although a sequence presumably is required to insure fluid movement across steps).

So your statement regarding use of the Model 3 API for coordinated motion when you do NOT define a coordinate system inside the controller makes me wonder:  How DOES it insure the motion IS coordinated in such cases?   This would seem to be particularly important for more complicated motions such as in your example.

Perhaps my confusion stems from using a stricter definition for "coordinated motion"?  To me it refers to the need to insure that the motion of multiple motors is synchronized at all times so the motion of what they are controlling is always what it should be.  One of the more demanding examples that comes to mind is one of those 3D printers where there are 6 motors controlling the position and trajectory of the print bed:  Any loss of synchronization could potentially ruin the result.  And fluid transitions across each step in a sequence of moves is a must.

Mark Davis
NSCL/FRIB
Control Systems Software Engineer
davism50@msu.edu

On 4/18/2019 1:53 PM, Mark Rivers wrote:

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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of Davis, Mark via Tech-talk
Sent: Thursday, April 18, 2019 9:51 AM
To: tech-talk@aps.anl.gov
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 davism50@msu.edu