Issues with ProfileMove API in PVT mode.

[MarkRivers]

I am seeing errors that I don't understand with the ProfileMove API.

The following is from an IDL script that builds profiles and attempts to build and execute them.

abs_position = [15.0, 14.5, 14.0, 13.0, 12.0, 11.5, 11.0]
rel_position = [-0.5, -0.5, -1.0, -1.0, -0.5, -0.5]
array_time   = [ 2.0,  2.0,  2.0,  2.0,  2.0,  2.0,  2.0]
fixed_time = 2

t = caput(profile + 'PROFILETYPE_CMD', 'PVT')
t = caput(profile + 'TimeMode', 'Fixed')
t = caput(profile + 'FixedTime', fixed_time)
;t = caput(profile + 'TimeMode', 'Array')
;t = caput(profile + 'Times', array_time)
num_elements = size(abs_position, /n_elements)
t = caput(profile + 'M1MoveMode', 'Absolute')
t = caput(profile + 'M1Positions', abs_position)
;num_elements = size(rel_position, /n_elements)
;t = caput(profile + 'M1MoveMode', 'Relative')
;t = caput(profile + 'M1Positions', rel_position)
t = caput(profile + 'NumPoints', num_elements)
t = caput(profile + 'M1UseAxis', 'Yes')
t = caput(profile + 'Build', 1)
wait, .1
while 1 do begin
  t = caget(profile + 'BuildState', status)
  if (status eq 0) then break;
endwhile
t = caget(profile + 'BuildStatus', status)
if (status ne 1) then begin
  t = caget(profile + 'BuildMessage', message)
  message = string(message)
  print, 'Error building profile: ', message
  goto, done
endif

; Start MCS
num_points = 1500
t = caput(mcs + 'NuseAll', num_points)
t = caput(mcs + 'EraseStart', 1)

; Start move
t = caput(profile + 'Execute', 1)
wait, 1
while 1 do begin
  t = caget(profile + 'ExecuteState', status)
  if (status eq 0) then break;
endwhile
t = caget(profile + 'ExecuteStatus', status)
if (status ne 1) then begin
  t = caget(profile + 'ExecuteMessage', message)
  message = string(message)
  print, 'Error executing profile: ', message
  goto, done
endif

It moves a single axis between position 15 and 11. The motor record fields are:

VMAX=1.0
VEL=0.5
ACCL=1.0

The motor moves the motor to position 15 before building and executing the trajectory.

The script can move the motor either in absolute mode, or in relative mode by changing which 3 lines are commented/uncommented. The motion should be the same because the relative moves are simply the deltas of the absolute positions.

The script can use either TimeMode=Fixed or Array by changing which 2 lines are commented/uncommented. In Fixed mode the time is 2 seconds per segment. In ArrayMode it is 2 seconds in all segments, so it should be the same as Fixed time mode.

The step out signal from the Galil is fed into a Multichannel scaler running at 0.01 seconds/bin. The counts/bin are used to compute the velocity, and the integral of the counts/bin are used to compute the position.

There are 4 cases:

1. Absolute positions, fixed time mode
2. Absolute positions, array time mode
3. Relative positions, fixed time mode
4. Relative positions, array time mode

Case 1, absolute positions, fixed time mode

This mode works fine. This is a screenshot of the medm screen after the profile move is complete. There are no errors in the build or execute operations.

This is the position computed from the MCS data

This is the velocity computed from the MCS data

Case 2, absolute positions, array time mode
This works when all of the segment times are the same, 2.0 seconds as shown above. However, if the time for any segment except the first is changed to 3.0 then the profile builds OK but the execution fails with an error indicating an error downloading that segment, for example if array_time=[ 2.0, 2.0, 2.0, 3.0, 2.0, 2.0, 2.0] then I get this error:

Error downloading segment 5

This time array works fine:

array_time   = [ 1.0,  1.2,  1.5,  1.6,  1.8,  2.0,  1.5]

But if the time in the last element is changed from 1.5 to 2.5 it fails:

array_time   = [ 1.0,  1.2,  1.5,  1.6,  1.8,  2.0,  2.5]

with this message. Why?

Error downloading segment 6

Case 3, relative positions, fixed time mode
This fails for the relative positions shown above with this error:

Seg 5: Vector zero move distance, reduce time, add motors, and check profile

I have determined empirically that if any 2 successive relative positions are the same it will generate this error. If there are no successive identical values then the error does not occur. This seems like a bug, because 2 identical values will not be a zero move distance in relative mode.

I changed the relative moves from [-0.5, -0.5, -1.0, -1.0, -0.5, -0.5] to [-0.5, -0.6, -0.9, -0.8, -0.7, -0.5]

The profile then executes successfully. However, the motion is incorrect. The relative motions above sum to a net motion of -4.0.

This is the actual motion and velocity:

Note that it only moved by about 0.85 mm, not 4.0 mm. Why?

Case 3, relative positions, array time mode
This has the same problem as case 2, large changes like this with one 3 value array_time = [ 2.0, 2.0, 3.0, 2.0, 2.0, 2.0, 2.0] generate this error:

Error downloading segment 2

If this time array is used instead the profile executes, but the positions are still wrong:

[MarkRivers]

I then tested Linear mode rather than PVT mode.

• If 2 successive position array elements are the same in Relative mode this error is generated, just like PVT mode:

Seg 5: Vector velocity zero, reduce time, add motors, and check profile

• The actual motion trajectory is wrong in Relative mode. This is the actual position and velocity with:

rel_position = [-0.5, -0.6, -0.9, -0.8, -0.7, -0.5]
array_time   = [ 2.0,  2.0,  2.0,  2.0,  2.0,  2.0,  2.0]

Note that it only moved 0.8 mm, not 4.0 mm. The velocty in the first segment should be 0.5/2.0 = 0.25, but it is actually 0.05. Why?

[motorapp]

Case 2. I can only test in Linear mode, and can't replicate the fault on hardware (older). I see an issue swapping between fixed time and array time. It seems the array time data can be lost, and the PV has to be pushed again. However, this time array issue I believe to be outside of the Galil EPICS driver and so I've not looked at it today.
Recommend inspecting the text file TrajectoryScan.trj for errors. The file format for the move commands in PVT mode is as follows:

(segment time in seconds) (Position increment, velocity target, segment time in servo ticks)
It should be delivered to the controller as:
PV=<Position increment, velocity target, segment time in servo ticks>

All other cases:
The driver expects the position array to contain absolute position data, regardless of the move mode selection (absolute or relative). This can be changed if required. Below is the current theory of operation.

Position array treated as absolute position data. The driver treats the first point in the position array as the start position. If the driver is given an absolute position array, the driver can derive the equivalent relative position array that is 1 element less. However, if the driver was given a relative position array, there is no way to derive an absolute position array from the provided data. Both linear and PVT move commands to the controller require incremental move distance. In absolute move mode the motor will go to the first point in the position array, the start point, before the profile is started with the first incremental move. In relative move mode, the motor won't move to the first point in the array and will begin with the first incremental move from it's current location.

In other words, the effort required to compute the relative position array from the absolute one is performed by the driver always, not only when the user requests it. The profile is always 1 segment (point) less than the provided absolute position data. The strategy potentially saves some network bandwidth. Well, that's the theory anyway.)

Let me know how it goes. Thank you.

[motorapp]

Let me know if changes are required. Cheers.)

[MarkRivers]

I have not had a chance to get back to this yet, but I will.