PID tuning and accelereation

Weird? I wasn't even running programs, just tuning the servos.

I'll try again. Maybe I forgot to adjust ini.traj_default_acceleration / ini.traj_max_acceleration.

> Does the tuning tool know how to tweak those?

New commit (2.6) makes it possible using a gui (axis) that supports a [HAL]POSTGUI_HALFILE

git.linuxcnc.org/gitweb?p=linuxcnc.git;a...c686b111565f049de1c0

It seems I did something wrong: it is possible to adjust acceleration by setting the ini.XX parameters.

Would this also work from within an M-code that executes a small bash script? That is a queuebuster anyway.

Changes to ini hal pins are seen promptly in hal but milltask, the userspace task controller for LinuxCNC, samples the ini hal pins when it is _not_ running a program (or mdi command).

So the settings established by ini hal pin values are used throughout a program run.

Implementation of ini hal pins is a convenience that allows a user to alter some inifile settings without stopping linuxcnc, editing the inifile, and restarting linuxcnc. This can be useful when one wants to try different values while observing behavior with auxillary tools like halscope, halshow, halmeter, sim_pin, etc. since these programs need to be restarted too.

Changing them in an M-code could have unexpected results as new values would take affect in the _next_ program run.

OK, clear. Still not too bad; before loading another program I can execute the M command in MDI or hook the ini.XX change to a button in GladeVCP or so.

At least it makes it easier to execute a roughing program using high velocity/acceleration toolpaths (and jerk) and do a finishing program using somewhat slower settings to improve accuracy when desired, and all this without restarting and rehoming.

So I am happy with it .

I tried it once on the BF20 which doesn't have a very stiff Z column. Roughed out a block of aluminium with fairly high velocity and acceleration and finished with a much slower acceleration and feedrate reducing chipload to almost rubbing. Combined with a 4-flute cutter it did seem to help in obtaining that yummie mirror-like finish on aluminium. But having to restart LinuxCNC, re-home, etc. is a bit too much of a hassle.

Of course it is just a cheap patch for a machine stiffness issue. Acceleration is what loads the machine frame the most (when using small cutters). Reduce acceleration and deflection reduces too. And the human eye is very well capable of seeing surface irregularities in the few-micron order of magnitude. No idea yet how the new machine will perform in this department (still not finished construction); that one is much stiffer. But that one also does much higher accelerations and velocities by default.

What one really wants is jerk-limiting, I suppose. I tried doing that between motion and servo by using limit3, but that only allows taking off the sharp edges otherwise the following error rises too much. The new trajectory planner seems to reduce jerk a bit anyway as a side-effect due to the insertion of arcs, but it is not structural.

Jerk limiting is indeed what I need, but with no other ways of controlling that I turned to acceleration limiting. And as you saw I found it more difficult than expected. But that might have something to do with it not being asked for previously. And if nobody ask for something I can understand why It's not put effort in to it.

For my own part I have found more problems though.
As a starting point my mill should be one of the more rigid and sturdy machines out there. Isn’t that one of the strong sides of Mahos? I have also heard them being the more accurate machines that comes, at least from that time period.
So my disappointment was great when I discovered my mill is more or less worn out. Or at least is worn to a degree I have to make serious effort to correct for it. The more I work in it the more I come to believe it’s the reasons I have to problems I do.

The thing is, I have been able to make the original controller work (with hundreds and hundreds, if not thousands of hours literally used to fix it). And from what I gather it's not that bad. It moves as expected, and doesn't have any of the problems I experience with the other controllers.
But when I try to use other controllers and try to do the PID tuning I'm not in any way able to make it work satisfactory.

My first attempt was with a Galil controller (which I would consider high end). I even bought tuning software for it to do the tuning automatically for me. But I wasn't really able to make it behave as I would expect, and nothing like it does with the original controller.

Due to other circumstances I have put that whole (Galil and CamSoft) system on the shelf. I could put it back though, as I have made all interfaces identical. I can even hook the old controller back up and make that work. I think I have to do that soon just to verify how it behaves compared to the other control systems.....

I have now made serious attempts at using LinuxCNC with Mesa 5i25 and 7i77 hardware. I know others have used Mesa hardware with success on other Mahos with similar drives. And there is no reason it shouldn't work.

Anyway, I'm not entirely sure of why, but I'm not able to tune the axes in LinuxCNC.
I'm able to get it to behave almost perfectly when moving at high speed. The only visible problem is that all axes have some form of resonance, and keep hunting back and forth one encoder count. This hunting isn't possible to get rid of by increasing deadband, which makes me curious as to why. I will add a small amount of backlash comp to see if that will make a difference.

Anyway, I have attached a screenshot of how it looks in halscope with one axis coming out of movement while the others are still (supposed to be still anyway, they aren’t…. as can be seen. The hunting can be heard on the sound of the ~2 kHz square waves to the motors. And the servo motors keep hunting back and forth very clearly visible. This is true with only P set to a non zero value as well.

Does anyone have a clue of what the problem can be.

BTW, I’m not able to add any D to the system without it starting to resonate. On the other controller the D component were 2-4 times as large as P. In LinuxCNC I can’t even set it to 1 when P is at 20. There is something very strange here, and I don’t understand what it is.

Is there anyone who think they got a clue as to what’s happening on my mill?

Anders

A couple of things:

For a velocity mode servo (when the drive is tuned properly) D is _not_ appropriate and
FF1 is arguably the most important tuning parameter.

Also you cannot compare Linuxcncs parameters with another systems as the
units may be totally different.

(This probably accounts for you being able to use more D term on another system)

A 1 count oscillation is inevitable with analog velocity mode servos.
You can however, lower the frequency of the oscillation by adjusting the drives
analog input offset (or adding an offset to the PID output using the pid.N.bias pin)

If the scale of f-error is millimeters, I would consider this as 'good'. One division is only 0,005mm and you are way below that. My servo's track a lot worse.