Axis Creep

Hello.

I have a Fadal (DC Servo Motors) retrofitted with linuxcnc. It is in metric mode (displayed screen resolution to .001mm).

I have tuned the servo motors PID loops and all axis' work well and stop accurately where they should (+/- .002mm).

In X and Y, once stopped the table stays where it is (naturally as they are in a horizontal plane with no gravity effects).

The Z axis is counter balanced (weight connected by chain), and from what I am seeing has a possible bias to being nose heavy. The reason I say this is that once the Z axis has stopped at its commanded absolute value there is often a slow "creep" with the nose (Z) moving downwards over time (increasing negative value). This is at a rate of .001mm per 15 seconds, in other words, over every 3 minutes the Z axis has the potential to drop .012mm. This can be cumulative, and as such if a surface is being faced off (commanded constant absolute Z value) over 5-10 minutes the Z can droop over the course of the cut by over .04mm.

Deadband is set to .00000001 on each axis. Z axis ballscrew has an 8mm pitch with 4096 encoder count. Beyond that I am not sure what I should/could be doing to stiffen up the Z axis to counteract the Z droop. In other words, after the Z axis has arrived at its absolute commanded target, subject to commanded deadband value, I would like the Z axis to "see" that it has drifted outside this threshold and actively correct to return/maintain the commanded absolute target value over time.

Could I get some thoughts on this please?

Many thanks,
Marty.

Does the DRO show the creep?

Yes, this is where I am seeing the numbers change. In other words, the DRO is showing the creep as the Z very very slowly drops (only occurs in the downwards direction) and thus the system is aware of the change, hence if the system is "seeing" the creep, what can I do or what setting can I tighten to have the axis "hold" that absolute position with a tighter tolerance?

Looking at it from another perspective, in absolute mode (G90), let us look at a facing operation.

Firstly a Z position is commanded and the Z axis moves to the commanded position, Thereafter, only X and Y moves are commanded, in other words the Z axis is left alone, in the position as previously commanded.

In layman's terms, once the Z axis is set to an absolute value is it monitored over time to ensure it remains at that absolute value? Or is it working under the assumption that unless subsequently commanded it will remain in the exact position as left? Almost in a pseudo modal sense are absolute axis target values actively controlled until another commanded position is issued or once set are they unmonitored and subject to this type of drift?

A servo system like LinuxCNC controlling a analog servo is constantly running and trying to correct the error
(the error is called following error in LinuxCNC)

For slow drifts, the usual correction is to add some integral term (I) to the feedback loop, so this is basically a
tuning issue.

I suspect that the cause of the drift is temperature drift in the drives analog input offset (and perhaps not very high velocity gain in the drive), something that a little integral term can fix.

Sorry about the time to reply to the responses given here as I have spent some time testing on my machine.

I would like to clarify that with this testing and in hindsight, I think I have described the drift in an erroneous context.

For simple facing jobs, I like to leave the machine in JOG mode, and come down with the Z axis and zigzag across the work piece by jogging. It is a quick and simple way of doing an uncomplex job, i.e. simply facing a part. When JOGGING the Z axis, I stop at a particular position in Z but without any further movement of the MPG the Z axis will then slowly drift with the .001's (mm) on the DRO slowly ticking over, ceasing its drift after about 3 minutes and .04mm of movement off the original stop position. Given this trend I thought that maybe it is the nose of the spindle settling under gravity (again the Z axis spindle is balanced by a counterweight) BUT, this movement occurs downwards if the initial jog was downwards or upwards if the initial jog was upward. Thus I cannot say that this drift is due to a lack of balance between the spindle and the counterweight as it drifts on both directions. It almost feels as though the control is very slowly "catching up" with latent MPG pulses still in a buffer.

In contrast to JOG (and as per PCW's post above) in MDI mode, when a command is given to drive to a certain Z position, the axis stops and does actively maintain that position constantly over time and the controller actively holds the following error to zero proactively maintaining the exact position. (In MDI mode the servo/controller/target remains active, whereas in JOG mode the controller/servo is not looking to maintain a target).

So for simple facing jobs, on one hand I have the simplicity of being able to fairly expeditiously jog down and potentially fine tune the height of the Z axis easily and then jog around in X and Y to compete the facing operation but with the drawback that in jog mode the Z will slowly move off position over the course of about 3 minutes and to a total extent of around .04mm. This becomes a little exasperating when jogging a few .01's up and/or down and then the Z drifts off that desired position over the course of doing the facing. On the other hand, I could have the machine in MDI mode and do the same facing job but enter all data via the MDI screen for Z, and then to do the facing operation in X and Y with G1's and feed rates which is somewhat clunky but actively monitors and controls the Z axis following error to zero (zero drift off target).

So I wonder what options I have here to maintain the simplicity of jogging around in Z and then X and Y for a facing job, but also preventing any Z axis drift which being in MDI command mode the controller would monitor and control?

If indeed it may be an issue of catching up on a few "buffered pulses" from the MPG in jog mode, is there a way to clear these from the controller by a line in the HAL file such that when jogging, if a pulse is not detected for say 0.5 sec then any remaining pulses not yet executed are deleted??

Any thoughts welcome.

Thanks,
Marty.

If this is only with jogging, its most like related to jog filtering, can you post your hal/ini files here?

Have you differnces when using other scalling factors?
I would expect less drift when 0.001 than 1.0.

I would watch in halshow the output of the encoder.

Hi Peter.

Below is an extract from the HAL file referring to MPG movement.

To help identify, the MPG is connected to a 7i84 set to encoder mode, it is the first of three 7i84's and is thus addressed 0.
Namely hm2_5i24.0.7i84.0.0..........

I seem to recall a section was included to smooth jogging motion but as I glance over the HAL file it is not apparent to me.

Complete HAL and INI files attached.

Thanks,
Marty.


# ---jogwheel signals to mesa encoder - shared MPG---

net joint-selected-count <= hm2_5i24.0.7i84.0.0.enc0.count

# ---mpg signals---

# for axis x MPG
setp axis.0.jog-vel-mode 0
net selected-jog-incr => axis.0.jog-scale
net joint-select-a => axis.0.jog-enable
net joint-selected-count => axis.0.jog-counts

# for axis y MPG
setp axis.1.jog-vel-mode 0
net selected-jog-incr => axis.1.jog-scale
net joint-select-b => axis.1.jog-enable
net joint-selected-count => axis.1.jog-counts

# for axis z MPG
setp axis.2.jog-vel-mode 0
net selected-jog-incr => axis.2.jog-scale
net joint-select-c => axis.2.jog-enable
net joint-selected-count => axis.2.jog-counts

# for axis 4th MPG
setp axis.3.jog-vel-mode 0
net selected-jog-incr => axis.3.jog-scale
net joint-select-d => axis.3.jog-enable
net joint-selected-count => axis.3.jog-counts


# connect selectable mpg jog increments

net jog-incr-a => jogincr.sel0
net jog-incr-b => jogincr.sel1
net jog-incr-c => jogincr.sel2
#net jog-incr-d => jogincr.sel3
net selected-jog-incr <= jogincr.out-f
setp jogincr.debounce-time 0.200000
setp jogincr.use-graycode False
setp jogincr.suppress-no-input False
setp jogincr.in00 0.001000
setp jogincr.in01 0.001000
setp jogincr.in02 0.010000
setp jogincr.in03 0.001000
setp jogincr.in04 0.100000
setp jogincr.in05 0.010000
setp jogincr.in06 0.050000
setp jogincr.in07 0.100000
setp jogincr.in08 0.125000
setp jogincr.in09 0.125000
setp jogincr.in10 0.125000
setp jogincr.in11 0.125000
setp jogincr.in12 0.125000
setp jogincr.in13 0.125000
setp jogincr.in14 0.125000
setp jogincr.in15 0.125000