Phidgets Forums

I'm tuning a 42DMW61 motor for position control using the Position Controller v1.9 (2022-01-12).

This motor has some errata on wiring and PID tuning, noted here.

The motor is confirmed wired properly, but I believe there's a math (sign) error in either/both the I & D properties. The motor runs differently when the commanded move is toward zero than moving away from zero.

The graph in the attached image shows the asymmetry. Note the attack when moving toward zero is different than moving away from zero.

Additionally, it appear the rescale factor is not applied to the PID parameters.

Rescale factor indeed does not affect the PID parameters.

If you repeat those motions 5-10 times, do you see the same results each time?

If I'm reading your example image correctly, it appears you are trying to move the motor a short distance (25 counts) very, very quickly. In this case, there may not be enough position resolution to get a perfectly consistent motion over such a short time.

Depending on your application, you can use the Velocity and Acceleration parameters to reign-in your motor's movement to a more consistent shape.

On the note of shapes and graphing, we have noted that the way graphing is done in the MotorPositionController example is less helpful at lower speeds, and will be fixed to plot positions based on the time they occurred to help better gauge speed and acceleration. You can expect this change in the next release of the Phidget Control Panel.

Hello. Thanks for getting back to me. I have some observations and suggestions.

I trimmed the motions for the purposes of visualization. The longer moves behave similarly.

Repeating the moves works the same way. I cleaned up my graph before taking the screen image.

I'm definitely tuning the system. These moves are with low stiffness. Without visibility into the code, I'm finding myself questioning things like: what are the units for P I D? Are the signs for PID properly implemented?

Bug list:
Pressing Zero Position does not zero the displayed Motor Position.

After zeroing position,the first move moves the the Motor Position + the Target Position
Set the Increment to 1, with displayed |Motor Position| > 1.
Expect |first move| = 1, observe |First move| = displayed |motor position| + first move.)

Feature requests:
Save settings should persist between saves. (Must press Select all each time).
Save settings should not post a modal dialog to confirm completion (another thing to dismiss). Show an in-dialog message instead.
On stall, record the tuning parameters somehow. Currently, tuning parameters are lost when the motor stalls.

Thank you for your suggestions for potential improvements, we will take these into consideration.

I was unable to replicate your results in-house. The motor I used moves with the same degree of accuracy regardless of direction. Is there some mechanical loading on your system that's stronger in one direction? Having looked into the math more directly (see below) I can confirm this is not a sign error.

As for what the PID parameters actually mean:

Kp, Ki and Kd are double-precision floating point, maintained even in the firmware. Precision on these is guaranteed.

Currently, PID parameters are expressly linked to internal parameters in the DCC1100. We know this is not ideal, and is slated to be greatly improved on our next pass through motor controllers.

For now, to give you something concrete to work with:

Position correction is scaled to position counts. The formula is Kp * error = "duty cycle number"
The duty cycle is tracked internally as a fraction out of 2097151 (0x1FFFFF)

Scale your desired Kp by a factor of 2097151, and you will get a result you expect.
E.g. a position error of 105 counts with Kp of 10000 will result in a duty cycle of 0.5

Ki is applied to the position error accumulated every millisecond.
Ki contribution = Ki * errorSum
Again, the result is scaled to the maximum internal duty cycle of 2097151.
E.g. Ki of 1.0 on a position error of 209 counts will take 10 seconds to reach a duty cycle of 1.0

Kd is applied as Kd * (error-perviousError) every millisecond, and is admittedly functionally useless on a motor controller with positions as sparse as those on the DCC1100. This algorithm was initially designed with high-density position encoders in mind, and here it really shows.

For completeness' sake, a change in error of 1.0 and a Kd of 1048575 would result in 0.5 contribution to duty cycle, for that millisecond.

Also keep in mind that the PID loop is handled relative to the expected position on the trapezoidal motion profile.