[Suumas]

I'm using KMotionCNC 4.30 in closed loop stepper mode with rotary encoders on the shaft of the steppers. I find that the tool position (according to KMotionCNC DRO) will build up an erroneous offset as more movements are performed, yet the switching to encoder view shows the correct position. The problems plays out like this:
1) Press the tool into clay
2) Zero everything, even reinitialize KFLOP to zero all axii and encoders.
3) Set Z-axis to -2 inches
4) Run moderately lengthy program with instructions at start to leave and end to return to the clay
5) Measure offset

When I measure the offset after running the program, I typically find an error that looks as though it's losing counts as it moves (move left and it will offset right a little bit). The KMotionCNC DRO shows X0 Y0 as though it returned to home, but switching to encoder view shows the actual erroneous position X-0.142 Y-0.0179. I moved the tool before I measure Z but I know from experience it's happening there too.

It's running in closed loop, so how can such a large error accumulate? Why doesn't it try to correct such a large error at some point?

KFLOP and GCode attached.

[TomKerekes]

Hi Suumas,

It sounds to me like the encoder feedback is probably the problem (loosing/gaining counts). If you zero the encoders so the raw encoder Position on the KMotion Axis Screen reads zero, and then later move back to the same physical position the Position should return to zero. If it does not then the encoder did not count correctly.

What type of encoders do you have? Differential or single ended? How are they wired? Is the wiring shielded? Length? If single ended, a terminating resistor at KFLOP may help. KFLOP has a digital filter that defaults to 7 (@16.67MHz samples) that can be increased that sometimes helps. But it sounds like the noise is quite severe and should be addressed first.

Regards

[Suumas]

I'm using singled ended encoders with 3ft unshielded wires, noise could definitely be a factor. I'll hook them up to my oscilloscope and see what the signal looks like in action.

For reference though, what's the cyan encoder view for in KMotionCNC? If that's the count from the encoders themselves, then the encoders are actually correct and the green commanded position is wrong. Does encoder noise still explain how the encoder view is correct and the commanded position is wrong?

[TomKerekes]

Hi Suumas,

From your description I can't follow exactly what you are doing and observing. I understand up to your step #4. But I don't understand what you mean by "measure offset" or where the tool is physically positioned when you describe the green and cyan values (and you didn't include the Axis Destination and Positions). Please be more specific it will be very simple to determine what is wrong with complete information.

The cyan values are the encoder reading. If the encoder is bad the servo will not know this and offset the motor until the encoder reads the desired value (but the axis will be physically in the wrong place).

The servo offset will be limited to your Max Output Setting. If the drift is larger than this then the servo will stop correcting and the encoder will not match the desired destination. Since you did not include your axis resolutions I can not tell if this might be happening.

Here are the basic formulas/concepts:

Green DROs = Theroretical Desired Destination
Cyan DROs = Actual Measured Position
Error = (Actual Measured Position - Theroretical Desired Destination)
Servo Output Offset is adjusted to make Error zero via PID+Filters
Commanded Motor Steps = Desired Destination + Servo Output Offset

HTH
Regards

[Suumas]

I mean physically measure offset at the tool from the 1st impression in the clay at the start of the program to the 2nd at the end. The physically measured offset agrees with the (cyan) encoder dro but not the (green) theoretical dro. The physical tool position may be -0.014, -0.017, the encoder view shows the correct physical position, but the theoretical shows 0,0.

X & Y axis:
20320 steps/inch
max following error 10^9
X: 7 linear backlash, 5080 rate
Y: 17 linear backlash, 5080 rate

Encoders:
1000 counts (4000 after quadrature)

[bhurts]

Wow is that ten to the 9th power following error. That would not keep you from scraping a part for sure. I haven't used the closed loop stepper setup but I assume it would need to be tuned similar to a servo. What do you have for p I and d settings? Also have you specified any dead band? Your max following error should be set to a value that represents the furthest you will allow the part from zero before faulting. I wouldn't think it should ever be set to equal more then .005 to .01 thou. Best thing to do is save a picture of your config and flash screen and your step response screen and post them here. You can open the config screen and hit the print screen button on your keyboard. Then open windows paint and hit paste. Save it and then do the same for the step response screen and post them here.

Ben

[TomKerekes]

Hi Suumas,

Ah, I think I see the issue. The MaxI setting is set to 200. I forgot that the I gain is doing all the work. So if the Integrator is only allowed to ramp to 200 then the max allowed correction will be 200 uSteps or 200/20320 = 0.0098 inches. After that the servo will stop increasing the correction and the position will drift.

If you increase MaxI (and you may need to increase MaxOutput at some point also) then the closed loop should correct the error assuming the encoder is counting correctly.

But you shouldn't have so many lost steps in the first place. What type of drives do you have? A common problem is to not have enough Direction Setup time. In that case the drive can sometime receive a step in the wrong direction when the direction changes.

Regards

[Suumas]

It's working, looks like it was the deadrange setting of 0 with backlash > 0 causing the PID loop to misbehave. I found that when I turned backlash compensation off it worked fine. I also increased max I and max output to 10^6. ...yeah I know...but accuracy is dead on now and I found I don't need the backlash compensation since tightening up the gibs before get to this issue. Now I need to go back and tune everything from scratch, namely calculate some numbers for low pass filtering and the PID values. That's for another thread, this issue is resolved.

Thanks for the prompt support and meaningful information right off the bat! Too many people like to start with "have you tried turning off and on again?" Now that I've gone through the documentation a bit more I'm really appreciating all the hard work and detail put into this.

[TomKerekes]

Hi Suumas,

Thanks you for posting back. Not sure why the backlash correction would be an issue. It was set to make a very quick motion in 1~2ms. Maybe that was upsetting the drives.

Regards