DRO innacuracy. Why would the DRO not reach the commanded position?

Offset table is stock. Triple checked now. No non-zero offsets other than 5220, which reads 1.00000 which starts up the system in G54 from what I read. The offsets were read from the .var file. And I double checked by setting the offsets through the gui, one by one. Each didn't change the original offset that showed when I homed.

When I move to 3" and touch off and set to zero it sets at -.0003" Then when commanded to -1" it lands -.9991" It's like clockwork. It's landing about a thou short every time.

I hope this helps. Because I'm as lost as anyone can be.

Scot

BTW, this reading on the DRO is not the DTG reading, which lands at zero and 1 respectively from that touch-off point it starts from.

The DRO reading comes from the left DRO. And each time when I go to -1" it lands at -.9991" Then if it moves back to the zero position, it lands at -.0009". This occurs at rapid or programmed feedrates.

I'll give it this much. It's consistent.

Scot

What's in the preamble? I think a G92.1 should clear any axis offsets. Long shot, does a G61 exact path mode change anything?

Also from user concepts:

1.5.3 When You're Lost
If you're having trouble getting 0,0,0 on the DRO when you think you should, you may have some offsets programmed in and need to remove them.

Move to the Machine origin with
G53 G0 X0 Y0 Z0
Clear any G92 offset with
G92.1
Use the G54 coordinate system with
G54
Set the G54 coordinate system to be the same as the machine coordinate system with
G10 L2 P1 X0 Y0 Z0
Turn off tool offsets with
G49
Turn on the Relative Coordinate Display from the menu
Now you should be at the machine origin X0 Y0 Z0 and the relative coordinate system should be the same as the machine coordinate system.

"What's in the preamble? I think a G92.1 should clear any axis offsets. Long shot, does a G61 exact path mode change anything?"

If you're referring to the active Gcodes in the bar below the MDI command bar its' G1 G17 G40 G20 G90 G94 G54 G49 G99 G64 G97 G91.1 G8 M5 M9 M48 M53 M0 F50 S0.

I don't know if G61 did anything.

If you're referring to another thing when you say preamble, like if there is a program running with the first line of Gcode being something, there is no other program running and I don't actually understand what the preamble is other than in an actual Gcode program in the top line.

Also from user concepts:

"1.5.3 When You're Lost
If you're having trouble getting 0,0,0 on the DRO when you think you should, you may have some offsets programmed in and need to remove them."

"Move to the Machine origin withG53 G0 X0 Y0 Z0"

Did it and it went into estop after a rapid falling about a half inch short of zero. There is ONE axis on this machine. I had to reset the servo drive to get it out of estop. And it repeats the same thing if I run that line in MDI again. Moving it slowly ends with the servo whining then going into estop.

"Clear any G92 offset with
G92.1"

The code is reading active in that bar I wrote about above. But I ran the code in MDI.

"Use the G54 coordinate system with
G54"

I ran it in MDI. The machine sits in G54, IDK if the G53 line did anything other than send the machine into estop and require a reset of the srevo. When I try and go past the .5" -ish mark the servo starts to whine and it freezes and the machine goes into estop.

I can get it to travel to a half inch over zero, no problems. Then I can move it incrementally to .4790" and it starts to whine, increasing as I move toward zero. I can stop it and move away from the zero point. But it would be really nice to be able to move it all the way down. This one is a head scratcher.

There is partial success, though. When I move the axis in incremental moves, it moves solid, exactly as commanded in .1" .01" and .001" increments. On the .0001" increments it hangs for bit and sometimes doesn't show a DRO move for about 3 or 4 moves. Sometimes it also jumps after a few pulses. i.e. when I pulse the button 3 or four times, it may move, it may wait. And it may not move until I hit it 5 or 6 times and then jump to a position that I didn't count pulses, to.

It's getting close, I guess. But that estop situation has me a bit concerned.

And from what I've gathered, unless I'm incorrect, the .var file is where all the offsets are stored.

Here's the .var file in case it helps. I'd take a screenshot, but it won't allow me to attach it to the thread. Nonetheless, this is the .var file:

5161 0.000000
5162 0.000000
5163 0.000000
5164 0.000000
5165 0.000000
5166 0.000000
5167 0.000000
5168 0.000000
5169 0.000000
5181 0.000000
5182 0.000000
5183 0.000000
5184 0.000000
5185 0.000000
5186 0.000000
5187 0.000000
5188 0.000000
5189 0.000000
5210 0.000000
5211 0.000000
5212 0.000000
5213 0.000000
5214 0.000000
5215 0.000000
5216 0.000000
5217 0.000000
5218 0.000000
5219 0.000000
5220 1.000000
5221 0.000000
5222 0.000000
5223 0.000000
5224 0.000000
5225 0.000000
5226 0.000000
5227 0.000000
5228 0.000000
5229 0.000000
5230 0.000000
5241 0.000000
5242 0.000000
5243 0.000000
5244 0.000000
5245 0.000000
5246 0.000000
5247 0.000000
5248 0.000000
5249 0.000000
5250 0.000000
5261 0.000000
5262 0.000000
5263 0.000000
5264 0.000000
5265 0.000000
5266 0.000000
5267 0.000000
5268 0.000000
5269 0.000000
5270 0.000000
5281 0.000000
5282 0.000000
5283 0.000000
5284 0.000000
5285 0.000000
5286 0.000000
5287 0.000000
5288 0.000000
5289 0.000000
5290 0.000000
5301 0.000000
5302 0.000000
5303 0.000000
5304 0.000000
5305 0.000000
5306 0.000000
5307 0.000000
5308 0.000000
5309 0.000000
5310 0.000000
5321 0.000000
5322 0.000000
5323 0.000000
5324 0.000000
5325 0.000000
5326 0.000000
5327 0.000000
5328 0.000000
5329 0.000000
5330 0.000000
5341 0.000000
5342 0.000000
5343 0.000000
5344 0.000000
5345 0.000000
5346 0.000000
5347 0.000000
5348 0.000000
5349 0.000000
5350 0.000000
5361 0.000000
5362 0.000000
5363 0.000000
5364 0.000000
5365 0.000000
5366 0.000000
5367 0.000000
5368 0.000000
5369 0.000000
5370 0.000000
5381 0.000000
5382 0.000000
5383 0.000000
5384 0.000000
5385 0.000000
5386 0.000000
5387 0.000000
5388 0.000000
5389 0.000000
5390 0.000000

"Set the G54 coordinate system to be the same as the machine coordinate system with
G10 L2 P1 X0 Y0 Z0"

I did after I brought the machine out of Estop and reset the servo. Don't know if it did anything. BUT on a good note, it goes to the programmed position on the nose when it homes. i.e. if I send it to the home position on startup or if I rehome it, it goes exactly to position.

Unfortunately, it won't travel past the half inch-ish mark toward that axis's zero at speed without going into estop or whining then reaching estop when I creep past that half inch mark. So half of the problem is fixed. But now it's screwed in a way it wasn't before. And worse, maybe.

"Turn off tool offsets with
G49"

Done.

"Turn on the Relative Coordinate Display from the menu
Now you should be at the machine origin X0 Y0 Z0 and the relative coordinate system should be the same as the machine coordinate system. "

Both relative and commanded are identical now. But it still will not go lower than .4760" without whining when crept past and locking out to estop when the G53 G0 X0Y0Z0 line is given or when anything bigger than incremental jumps at about .01".

Let me know what I'm missing.

Scot

Yes, the preamble is the startup code that defines the behavior of your machine. You should add it to the g code file you're running and have the basics in the ini file under rs274ngc section. (check the manual for proper details such as being in lathe mode G18)

Sorry if I wasn't too clear with the user concept I copied. It shows XYZ for mill coordinates. You should be looking at X and Z and only execute rapids or feeds on the axis you are experimenting with. The machine stopping sounds correct if you're trying to command a move that's not configured. I assume there was a joint following error?

I can get it to travel to a half inch over zero, no problems. Then I can move it incrementally to .4790" and it starts to whine, increasing as I move toward zero. I can stop it and move away from the zero point. But it would be really nice to be able to move it all the way down. This one is a head scratcher.

There is partial success, though. When I move the axis in incremental moves, it moves solid, exactly as commanded in .1" .01" and .001" increments. On the .0001" increments it hangs for bit and sometimes doesn't show a DRO move for about 3 or 4 moves. Sometimes it also jumps after a few pulses. i.e. when I pulse the button 3 or four times, it may move, it may wait. And it may not move until I hit it 5 or 6 times and then jump to a position that I didn't count pulses, to.

It's getting close, I guess. But that estop situation has me a bit concerned.

Not exactly sure whats going on here but I would configure a clean preamble in the ini first, set it so it's in lathe mode, G18, G20, G90, etc and codes to clear offsets, restart, home it and see how it behaves.

I would tend to agree with tommylight,
Especially on a PWM or torque based system make sure you have
enough I term to reduce static errors to zero quickly.

Do you only have a rotary encoder on the motor, or is there a linear glass scale involved?

When The DRO is reading off what does the following error equal?

If this is a torque commanded servo, 3-5 encoder counts might be as good as it can be tuned with Linuxcnc. If it is velocity commanded servo, 1-3 encoder counts could be possible.

Okay, well I'm embarrassed. Because last night when I started the process you outlined, I had forgotten that I had a bolt out of place with the head sticking out just enough to stop the axis a half inch or so before the zero point on that axis. So of course, when the slide hit the bolt, it sent the servo searching until the current rose to the error grew to an estop level event. That explains the estop and the whining. So let that be a cautionary tale to those in the mode of rebuilding and retrofitting a machine. When your machine is being configured and you have it opened in the mechanical places, make sure to double check if there is any potential obstructions! CRASH! BANG! WHHHIIIINE! ESTOP! Followed by: WTF?!

So I set that bolt back in it's proper place. Then I messed with things and got more issues. So then I went home to let the scenario roll around in my noggin. And realized what I had done to mess things up and what were obvious problems.

I fixed the obvious problems, one of which was having the home position identified as 5.25" and the minimum limit on that axis of zero. I redefined the home position as 5" and the minimum limit to -.25", effectively giving me the exact amount of distance the axis can move before tripping the -limit switch and allowing for 1/4" of negative, past zero for some play before that switch is tripped.

Then I redid the steps you outlined. But I noticed that the same thing was happening only to a slightly lesser degree.

I did have a question. Was I supposed to home this machine with the relative position being shown at the start?

I'll be reading more while waiting to see what you may be able to help me find that I did incorrectly. The thing is, the machine showed a much better landing position when I did the steps even after it crashed, but the last time I went through it and got the same results as I started with.

Not sure what I'm missing, but clearly I am missing something.

I got a pretty strong thumbs up from Jon when he saw my screenshot of the result of tuning with Halscope. From what I saw and was verified of, I was getting about a .00025" following error. But I'm going to bet that can be made a lesser number with practice. And it makes sense that it would be an issue when the machine resolution is .0001" and the following error is 2.5 times that.

So if I can't get this to set properly from the instructions I was given on this thread, I'll be retuning for the sake of double and triple checking along with practice. I hear the practice thing makes perfect, and such. Thanks for the input, sir.