What does PID mean for open loop steppers?

More
24 Oct 2018 00:06 #119303 by cogzoid
I'm employing open loop stepper motors. I've got no feedback from stepper motors back to the computer except for the homing switches. In such a situation, what does a PID loop do? Where is it getting its feedback from? I can imagine the "error" of the PID loop being the desired location minus present location, but what would the "output" of the PID loop be? The velocity? The acceleration? Something else? Sorry if this seems like a dumb question.

Would PID loops perform better than "trapezoidal" velocity profiles that Arduino GRBL uses? (Accelerate, Cruise, Decelerate). Would the calculation times for either of these be a consideration?

I'm trying to learn as much as I can about this system before I implement it...

Thanks for your patience.

Please Log in or Create an account to join the conversation.

More
24 Oct 2018 00:21 #119304 by cmorley
PID is there just to push the error of where you are at, towards where you should be.

Being closed loop or open loop only means where you are getting your 'where you are' position info from. Openloop is getting it internally and you are stuck with whatever 'PID- like' control loop that is coded

Most openloop implementations don't expose the control loop to the user.
In linuxcnc it does.
It was found with Mesa step drivers the 'internally closed' open loop had some problems that the PID ones didn't.

I'll leave smarter people to explain in more detail if you would like.

Chris M

Please Log in or Create an account to join the conversation.

More
24 Oct 2018 12:45 #119332 by andypugh

I'm employing open loop stepper motors. I've got no feedback from stepper motors back to the computer except for the homing switches. In such a situation, what does a PID loop do?


The LinuxCNC step-generators have their own internal limits on velocity and accelleration.

The feedback comes from the internal step-counter of the step generator. This can differ from the commanded position due to the velocity and acceleration limits, but also due to the slightly random times that the realtime threads are run. The PID can help to compensate for these limitation.

The Mesa configs used to run purely open-loop with the step-rate calculations done inside the driver, but this was found to be slightly sub-optimal (specifically on the Ethernet interface cards, I think) and now those configs are configured with a PID.

Please Log in or Create an account to join the conversation.

More
24 Oct 2018 14:04 #119336 by PCW
Whether you use the "visible" PID loop control or the built-in position control loop in the driver, LinuxCNCs hardware and software stepgens all use feedback to control the stepgens position

Basically the issue is that the in driver position mode control loop is not as robust with regard to servo thread jitter as a tunable PID loop (the in driver position loop is the same for the Mesa hardware stepgens and LinuxCNCs software stepgens and both have the same issue)

Also the PID loops tunability allows correction of minor errors caused by the delay between the stepgen position read and velocity update write so allows a reduction in the stepgens following error.

Please Log in or Create an account to join the conversation.

More
24 Oct 2018 19:59 #119354 by cogzoid
I did a little digging through the source code for PID loops and found a great explanation of how the PID loop is programmed. Just in case this is helpful for anyone else...
* The three most important pins are 'command', 'feedback', and
 * 'output'.  For a position loop, 'command' and 'feedback' are
 * in position units.  For a linear axis, this could be inches,
 * mm, metres, or whatever is relavent.  Likewise, for a angular
 * axis, it could be degrees, radians, etc.  The units of the
 * 'output' pin represent the change needed to make the feedback
 * match the command.  As such, for a position loop 'Output' is
 * a velocity, in inches/sec, mm/sec, degrees/sec, etc.
and
* The PID loop calculations are as follows (see the code for
 * all the nitty gritty details):
 *
 * error = command - feedback
 * if ( fabs(error) < deadband ) then error = 0
 * limit error to +/- maxerror
 * errorI += error * period
 * limit errorI to +/- maxerrorI
 * errorD = (error - previouserror) / period
 * limit errorD to +/- paxerrorD
 * commandD = (command - previouscommand) / period
 * limit commandD to +/- maxcmdD
 * commandDD = (commandD - previouscommandD) / period
 * limit commandDD to +/- maxcmdDD
 * output = bias + error * Pgain + errorI * Igain +
 *          errorD * Dgain + command * FF0 + commandD * FF1 +
 *          commandDD * FF2
 * limit output to +/- maxoutput

Please Log in or Create an account to join the conversation.

Time to create page: 0.266 seconds
Powered by Kunena Forum