mesa 5i25/7i77 Yaskawa servo

It sounds like something isn't connected correctly somewhere, Could you post a copy of your hal file?

Thanks Todd,

I've attached the HAL file. It's straight out of the configuration point and click.

cheers Ian

IanK wrote:

Thanks Andy, thanks Bevins,

The encoders appear to be reading properly. With the drives disabled, moving the motors by hand has the encoders seemingly responding correctly. I haven't tuned the servos yet, the motors are disconnected so without the inertia of the machine I had left that step out at this stage.
The machine does jog, superimposed over the background drift.

The PID gain is set to 50 for Proportional, 0 for I and D.

I've found that with F-error set to 200 Min F-error 20 that "Joint 0 following error" trips when it moves about 18 units (As indicated by the DRO) from the DRO reading just as the "Machine Power " is toggled on. It's jogging at about 3 times the speed of the drift. If by using the jog to keep the DRO within 18 units of the starting position I can jog indefinitely without "Joint 0 following error". Just can't let it drift or jog beyond the F-error limits.

The Watch window is interesting.
"X-pos-cmd" is frozen while the machine is powered but immediately picks up the reading shown on the DRO when tripped by the error or toggled to OFF

"x-vel-fb" always reflects the motor speed, whether drifting or jogging

"x-vel-cmd" is always reading zero
"jog speed" is always reading zero

"x-output" shows +_ 0.275 when actively jogging. It shows 0.025 when idle but Machine powered. It shows 0 when machine is not powered.
(That's the "machine power" toggle beneath the "E-stiop" toggle I'm referring to )

So it looks like the encoder signals are getting through to LinuxCNC but not being processed to influence " x-output".

Jog must be sending a raw, open loop signal to "x-output"


I must have a software connection not hooked in? It'll probably be an obvious omission of mine when I find out what it is.

Correct servo control should back off the drift shouldn't it? Keep the encoders stationary?

Thanks for your help.

Cheers Ian

The only potential problems I see in the hal file is the pins "setp pid.N.maxerror .0005" should be changed to a much larger number or commented out, if your config is metric.

"X-pos-cmd" is frozen while the machine is powered but immediately picks up the reading shown on the DRO when tripped by the error or toggled to OFF
Normal

"x-vel-fb" always reflects the motor speed, whether drifting or jogging
Normal

"x-vel-cmd" is always reading zero
Normal (it is using the joint vel-command until after homed and the kins switches out of joint mode.)

"jog speed" is always reading zero
Normal (this is an input pin used for setting jog speed with external buttons or on a pendant.)

What is the "pid-error" value when drifting? does it agree with "f-error" and have the same sign?
It might be you just need more tuning (more P) to get better following, or there might be an encoder scale issue.

Delete all statements of this type and you should be a lot closer:

setp pid.N.maxerror .0005
net N-vel-cmd => pid.N.command-deriv

You will now have working Feedforward and Feedback

BEWARE of RUNAWAYS, since the is the first time you will actually get significant analog output

Thanks all,
A good link on tuning Tommy, should be ready for it soon. Tried the other suggestions today but still confusing. But on the way home from the workshop this afternoon I thought maybe we could have the sense of the P feedback the wrong way around? Is there a neat way of reversing that or do I just set the P value with a minus in front? I'll try it tomorrow unless you have better suggestions overnight.

What makes me think this is that
. when P is set to 100 x-output is steady 0.5 volts and jogging adds +- 0.25 volts.
.when P is set to 10 x-output is steady 0.05 volts and jogging adds +- 0.25 volts.
Yaskawa drive and X motor responds appropriately to the input voltages.

I see that watching PID.x.feedback and PID.x.command they steadily diverge as the DRO drifts to a joint max-error
But despite this PID.x.output remains constant. Not the way I'd think a PID module should work. Unless it's wired in reverse and the output goes to saturation within microseconds?

Thanks for all your help on this.

Cheers Ian

Did you do what i suggested? If not, the behaviour you see is _expected_
(the maxerror setting bounds the PID output to P * maxerror and the feedforward is broken)

In addition, it sounds like the feedback is backwards
(you fix this by changing the sign of the analog output, assuming the DRO directions are correct)

Thanks PCW, yes I did what you suggested but with the PID feedback unknown at that time to be positive, it was worse, so I reinstalled those deletions. Unfortunately our oldish computer is refusing to boot up today, so progress has stalled before I was able to redo your suggestions.

I had trouble finding an elegant way to reverse X-output but changing output scale in the ini file from 10 to - 10 does the trick. Now with the machine toggled ON the DRO indicates that the drift we used to have due to the input offset voltage of the Yaskawa drive is controlled. (It’s a little shaky, but only a fraction of a millimetre vibration )

pid.x.error and axis.0.f-error agree in sign and magnitude.




So all seems well with feedback removing drift and holding a steady position as instructed by pid.x.command.

However when jogging, pid.x.command remains at the value when jogging was first commenced! Pid.feedback just follows the DRO leaving the pid.command signal way behind until a joint following error turns it all off!

I would have thought jogging was achieved under PID control by smoothly increasing/decreasing pid.x.command? Jogging at present appears to be achieved by bypassing the PID and just sending an open-loop signal to X-output. Maybe this mystery will resolve when we solve our computer problem and I redo your suggestions? This time with the feedback in the right direction!

Cheers Ian

No, jogging is not special, all motion is handed to hal via the commanded position
which drives the PID component. The commanded position obeys the trajectory planners
velocity and acceleration limits regardless of the source of motion (gcode or jogging)

These deletions are _mandatory_, these are not guesses:

setp pid.N.maxerror .0005
net N-vel-cmd => pid.N.command-deriv

Overshooting/undershooting is guaranteed if FF1 is not correct and
will be especially bad if you have not deleted the maxerr line

Too much FF1 will cause the actual position lead the commanded position when in motion,
too little FF1 will case the actual position to lag the commanded position when in motion

Thanks PCW. Now the computer is fixed I've re-applied those deletions with output scale = -10 and now jogging and G code input to the MDI works as expected. (Well as far as can be ascertained with drive belts disconnected).

I did just notice on the ini file I've somehow got Max-output set to 1.0 for x axis but 0.0 for the Y and Z axis.

A search on linuxcnc.org/docs/2.6/html/config/ini_co...ml#sub:HALUI-section indicates that Max-output refers to an extra addition/compensation to the primary PID output? Can I have some clarification on this please? It's obviously not disabling for the machine if set to zero? I'd assumed that output-max-limit which I've set to 10 refers to the max voltage that can be sent to the servo drives.

Thanks again
Cheers Ian