Positioning with PID Loops

Hi

Trying to figure out the best way to position two axes, to commanded positions. No motion planning/kinematics, it's simply a positioning job for a backgauage.

Now, I'm trying to figure out the best way to do this. Once the axis has been positioned, it needs to be disable, so the next axis can be positioned. This means that the PID loop or whatever controls it has to output that it's at position, so the enable can be turned off.

So far I can't see a way within a PID loop to get this feedback. The problem is that if I test for the position outside the loop, then I have to accommodate for "noise", plus at some point I need the loop to give up trying when the position is within a small range and is unable to get closer - the test will not understand this and will never read as in position, meanwhile the PID loop has stabilised. It seems to get complex without solving the core problem cleanly.

In short, the axes are closed loop, and need to be commanded to a specific position - once the position is reached the control should be disabled. The loop needs to control the speed to allow for high speed movement and low speed final seeking.

Simply wanting something like "go to 103.45mm", when it reaches "103.45mm+-0.05", it says "done".

This is pretty much what a homing sequence does - how is that achieved? And can I get dynamic speed control so that for greater distances it moves at higher speeds, and when getting closer the speed reduces (proper accel/decel curves)?

Thanks
J

On the surface this seems like it should not be all that hard. But in practice maybe it doesn't work. Here is the first thing I would try. I would use a small deadband in the PID settings, and feed the PID following error to a Near component equal to the deadband (or slightly more), Then the final step I'd feed the output signal from the near comp through a Debounce comp with a delay interval set to approximately what is needed for the settling time for the system. The output from the debounce should be the in-position signal you need.

Thanks Todd...

I was reading up on the use of limit2 and limit3 for softstarts, and wondering if it may be easier to make a very simple mechanism that seeks the position using a ramp up and ramp down…

Limit2 is an excellent way to set up a rudimentary motion control for non axis controlled joints.

Switching between control of your two different motors with one drive, sounds like a job for a PLC like Classic ladder.

It would involve a lot of sequencing of muxed inputs and switches. Your 2 position commands muxed to the PID, two encoder feedbacks muxed to the PID, the sets of contactors between the motors and the drive, the breaks for each motor. PID and Drive enable/disable (Are you sure you don't want to just buy another drive.) It all seems very complicated. But an interesting puzzle to work though, but could be a huge time hole.

At the moment I don't need any motion planning - in the future, it'll be debatable, but I'll have more axis on the back-gauge - again it'll be positioning, and the motion planner and kinematics will just position in pretty, smooth blended ways (absolutely not necessary!). But I'll be putting either a second VSD, or swapping the back-guage motor for a pair of servos or clearpaths, which'll solve some of the dumb stuff.

I wonder if I can use Limit2 to do the motion control I need then, instead of PID?

With the two motor/one drive control, I've wired it up using some XOR and AND gates... It's actually simple, clean and with the XOR, if we ever get a 'race' condition of both motors trying to be drive at once, then neither will operate. No feedback from that, but safety first... Plus the pins are there to wire the status of the XOR and per motor status into to give that feedback when I need it (using an AND for each then).

At the moment, I have a + and - button in the UI for both motors, and can control both without any issues. If I had multi-touch, then simultaneously pressing any combination of +/- for either motors would stop the motors!

As a reminder:
- VSD has a fwd enable and rev enable. That's controlled via Spindle Enable which is routed by a relay to either fwd or rev.
- The relay is controlled by Spindle Direction, and fwd is on the NC and rev is on the NO output.
- The VFD 0-10V speed is controlled by the Spindle Output... Currently set in the HAL config to a nominal value for testing.
- Both motors have their own encoders.

See, I was actually thinking in the other direction - having two PID loops, and then the output would be muxed... All I need to do is enable or disable the PID when that motor needs positioning, and it'll move it to whatever the command input for that PID is. That's why I need to figure a way of determining if the motor is in position, so I can turn the PID off!

My issue at the moment is not with the single dive/two motors - I think I have that in the can. My problem is that I want to position an axis and then disable control of it. I can't/should never move the Y axis when the beam is lowering, and the X axis is a back-gauge and shouldn't move until pressure is applied against the metal (at which point I'll retract the back-gauge to prevent the metal catching on the back-gauge). In fact, it shouldn't be possible to lower the beam until a "in-position" signal is sent back to the machine - for safety, to prevent dumb stuff (like damaging probes) and ensure the operator knows that they can proceed.

Ohhhh, evil idea...

Unless I'm mistaken, then the PID output will be a velocity, and either positive or negative...

I'll need to convert this to +0-10V along with a fwd/rev signal.

To quote Andy's answer here: forum.linuxcnc.org/24-hal-components/329...rol-with-7i76e#94556

I think the trick is to pass the output of the PID through an "abs" component.
"abs" helpfully has pins that indicate of the output is positive or negative.

position -> pid -> abs -> spinout.

linuxcnc.org/docs/2.7/html/man/man9/abs.9.html

So, if the output from the PID is 0, then the ABS is-positive and is-negative will both be false. That therefore should mean that the PID is done in achieving the current commanded position. So, the PID's own output reaching zero, should be the switch to turn off the PID.

I've not played with the PID module in this way or for this application, so I'm not sure what the signal will look like, but I presume the PID code should include some form of acceleration and deceleration curve (unless that would be handled by the motion planner, spoon feeding the commanded position over a suitable time base). So, I might need to add a limit2 to the commanded position.

Oh well, let's try this out and see what explodes.

enable -> AND.1.in0

AND.1.out -> pid.enable

ABS.is-positive -> AND.0.in0
ABS.is-negative -> AND.0.in1
AND.0.out -> NOT.0.in
NOT.0.out -> AND.1.in1

or something like that.

Perfect! I didn't realise error gave the difference...

I'll build this out tomorrow and see how I go...

So, managed to build all this out today, and whilst still need to tweak the PID values, it's working nicely!

The axes position at speed and with the LIMIT3, have nice acceleration and deceleration. The WCOMP on the PID error output identify when the axis is in position - they also help to prevent oscillation and overshot from the PID. The hardest part was the mechanism that is latched when the "GO" button is pressed and unlatches when it reaches position. I'm handling that now via flipflops - which could also be linked to the limits to stop the PID if it goes out of bounds, and even to the jog.

Need to figure out how to integrate a few things with the PID/motion:
- jog
- limit switches

And other stuff:
- X retract (when machine is either at specific Y0 position or pressure increases)
- sequencing (via Python userspace or GladeVCP)
- interlock movement of Y with Y0 position (prevent Y stoppers from being driven into the beam)
- interlock with "in-position" and machine operation (all bits there, just need to do it)

Because it's a manual homing process (the origin of both axis is relative to the tooling fitted in the brake), it's a little screwy when the origin is off and you're commanding to a position. I'll need to add a jog, but not sure yet how best to do it. One thought is to add/subtract a value to the PID commanded position (versus directly actuating the motors), like +1mm, +0.5mm etc. Not sure how LinuxCNC handles that?

Now something that I do need to figure out are the limit switches and how best to handle them. From what I gather, reaching a limit in LinuxCNC causes an error, which in turn stops everything. On that basis I'm wondering whether to just use the limits to trip the PID "enable" (via the flipflops), to directly stop motor outputs or to go more extreme (like disabling the machine). In reality I just need the UI to handle ranges to prevent out of range movement (but a mode that ignores this for the homing process) and then something to stop machine damage... any suggestions?

I need to do a sanity check with all the config, but importantly I've put limits into the PID and LIMIT3, which prevent dumb stuff...