Synthetos Shop

TinyG edge drifts on series of small movements

From the original Synthetos forum (2011–2025)

Started by flux on in TinyG Support. 68 replies, last activity May 29, 2014.

flux #

Greetings fellow CNCers!

I switched my firmware to edge (412.02) to use its Z-probe for doing PCB's. And that part is working great :). (For people who haven't tried it: G38.2 (position) and it tries to move towards the position till the Zmin end switch closes, and then it reports the absolute coordinates.)

However, I also noticed that my device X and Y offsets drift during the operation. The G-code I'm using is generated from Eagle using pcb-gcode, but it itself is not anything special. I found a small reproducible test case that causes a drift. The amount of drift it causes varies from run to run. Here: http://www.modeemi.fi/~flux/tinyg/test.gcode . My settings are at http://www.modeemi.fi/~flux/tinyg/tinyg-settings.txt .

For me this introduces a small ~1 mm drift in X, sometimes in Y, sometimes nothing. If I run it many times the error doesn't seem to always add up. I have longer examples that produce bigger drift, but I think this short sample should capture the essence of it.

At times I've it actually goes in completely wrong direction from the get-go and loses position that way :-o. (Ie. going in -X instead of +X, and it's not just that the commands are going in wrong, because the X offset permanently moves after that one wrong move.) This leads me into thinking this behavior is related to the 'edge' branch, as I have never seen that on master.

The problem occurs also without using the spindle, so I highly doubt it's because of the machine itself, also my belt-driven system doesn't seem to exhibit that kind of backlash.

All those tests have been executed in coordinate system 4 (you can see the offsets from configuration). I have homed the system with G28.2 X0, G28.2 Y0 and G28.2 Z0.

This is the first time I notice the problem (after making the machine work with aluminum plates), and I have changed two things: I have switched to the Edge branch and I have started doing PCBs (so much smaller features than before; and my typical CAM does arcs, not small-line segments). Sorry, I have not yet tried again with master, it's annoying to reset the settings :) (plus the Z probe is essential for starting real convenient PCB milling). But at least I spent a few hours finding the minimal case :). Hopefully this information leads to some findings.

Happy Easter :).

cmcgrath5035Staff #

flux- I am a bit confused; you say you are running tinyG 412.02. Where did you get that from? I have seen (and use) 412.01 and know that Alden built a 421.06 as a bug-fix experiment, downloadable from a dropbox.

What are you using to run your GCode? I am using tgFX, build 3009.
tgFX seems to have issues running with 412.01, Riley is about to deliver an updated tgFX build to work with tinyG 412.01 (and later).

Is the offset/drift you report seen in the milled result, or in a diagnostic window?

You might wish to review a rather long thread here:

https://www.synthetos.com/topics/tests-with-updated-tinyg-and-tgfx-versions-linux-environment/

My issue with the diagonal line offset is unresolved at this point, but might be related to what you are seeing.

flux #

Ah, I should have clarified that I'm using the latest version from Git; where does one even get precompiled edge firmwares? So I'm using Git version 8443a89158fee28a8b1d9be518d0cc74b6e3585f which is 412.02. I compiled it myself on Linux. 412.06 does not seem to be available on the Git repository.

I'm using a tool of my own writing for uploading the G-code (http://github.com/eras/tgup), as I was unable to make tgFx work on Linux. This does not affect this issue though, as it does not send any offset-reset commands (ie. G92), it only knows to send the commands that are present in the source gcode file. So for example missing characters would not cause this (and the program does proper queue management plus RTS/CTS handshaking) except in exceptional circumstances. But it is of course possible that my upload program is hiding some diagnostics response from TinyG, maybe I should change it to be more verbose.

I see the offset in the milled result. In fact, I can see it even without milling, in the position of the head when I G0 move it to a known location, after running the job in air. (I use a terminal program for sending interactive commands.)

Thanks for the link, but I think it's not the same issue, as the issue there doesn't seem to have signs of machine offset getting changed. In my case the machine offset changes so that it can only be restored with commands such as G92 or G54. G0 X0 might even ride through the end stop without resetting the offsets.

flux #

It seems that there have indeed been some biggish changes (inverse feed rate mode) between 412.01 and 412.02 (more than I actually first thought), so I should probably try 412.01 first (though from the diff it looks like the chances of affecting my issue are near zilch).

The probing stuff is unchanged from 412.01, so I still get to keep experimenting; perhaps I should then try master, if that doesn't help.

Thanks for pointers!

flux #

I tried the released 412.01 binaries, and sadly the issue still persists.

However, I also tried with 380.08 (master) as well, and it did not have the issue. So it would seem that the edge branch introduces the error - I hope these reproduction images will be helpful in finding the issue.

I think it's not going to be very realistic to pick the probing code from the edge to master, so I guess I need to make-do with the end-stop searching feature.

Thanks for all the help!

cmcgrath5035Staff #

flux - I have zero experience with multiple coordinate systems, so have been studying your config file just to see what it looks like. I don't know what type of machine you have (you mention belt drive). Mine is a ShapeOko. Here is a recent config from my machine

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Test4/2014-04-03_14.00.05-tinyg.conf

Your motor setups are similar to mine, although you have more travel per rev on X and Y. We both seem to have X-dual Y-Z machines (4 active motors).

What I did notice in your config (from your first post, a run with 421.02)
1. I have not seen prior to this anyone running tinyG at baud=230400. It is a valid option, so I can only assume you are confident it really works well at both ends.
2. Your X jerk, y jerk and z jerk maximums are way larger than I have, which may be part of my problem. For example, your z jerk max is 500 * 1 million, where as mine is only 5 * 1 million. The recommended starting point for my machine is 5000 * 1 million.
I'll assume you have good reason to be at 500, I appear to have missed 000 in translating my jerks from 380.08 notation to 421.01 notation. I plan to rerun my test again with 5000 *1 million settings.

Finally, you say

So it would seem that the edge branch introduces the error – I hope these reproduction images will be helpful in finding the issue.

What did you mean by reproduction images? Did your try to insert an image?

I am off to retest (again...). I'll let you know if you fixed my problem :).

flux #

Hi!

Hmm, so you tried the G-code on the 412.01 you have? Here's another G-code program that reproduces a bigger gap on 412.01 (but it takes ~3 minutes to run on my relatively high speed settings): http://www.modeemi.fi/~flux/tinyg/test.7.gcode . It can introduce a 10 mm x offset in the machine position.

I have zero experience with multiple coordinate systems, so have been studying your config file just to see what it looks like. I don’t know what type of machine you have (you mention belt drive).

I too have a ShapeOko (2). I have equipped its x/y with Nema23 motors.

I'm doubtful the coordinate systems are to blame, as I imagine that's a feature that's used a lot professionally - and everything seems to work fine in the master. And the coordinate system feature is quite nice! I can set one point to be the center of the machine, another to point to the origo of my PCB fixing spot and the values persist over restarts. Just start the machine, home it, and G57 G0 X0 Y0 Z0 goes to where the PCB is.

1. I have not seen prior to this anyone running tinyG at baud=230400. It is a valid option, so I can only assume you are confident it really works well at both ends.

I think this part works OK, also it can only realistically introduce errors in communication (which I haven't witnessed, such as completely invalid moves), not an offset to the machine position.

2. Your X jerk, y jerk and z jerk maximums are way larger than I have, which may be part of my problem.

I've found the jerk settings by just moving some distances, finding big values that still work, and then downsize to a serviceable value. Hasn't caused trouble this far (milling wood, aluminum) of course it depends on the job what the feed rate should be.

I actually halved the jerk values when trying to narrow down the problem, but it had no effect. I also tried both lowering and increasing the x/y junction deviations (0.01, 0.05) but it also had no effect. I also tried exact stop mode, but it had no effect.

What did you mean by reproduction images? Did your try to insert an image?

Oops, I actually meant the G-code program, not an image.

Btw, a related thing I _think_ I noticed when running the test on 380.08: I heard the clicking sound that is fixed in edge. I didn't hear those in the edge version. It could very well be that the fixes related to eliminating clicking (so the sudden stepper adjustments?) also affect this issue.

cmcgrath5035Staff #

Hmm, so you tried the G-code on the 412.01 you have?

Nope, I just looked at it. Actually, I loaded it into my CAD simulator just to see what it did.

If I get a chance, I will run this latest code to see what I see.

Is this a correct definition of what you call drift?:
1. Set Start = X0,Y0
2. Run GCode
3. G0 X0 Y0
4. Drift = difference between current position and Start (defined in step 1.)

FYI, I re-ran my GCode of diagonals (the long forum thread referenced earlier) with the recommended $xjm = 5,000,000,000 rather than my 5,000,000. It did not affect the cut pattern (where F=200), but the moves between open ends of unconnected parallel lines noticeably faster, per the definition of jerk.

Btw, a related thing I _think_ I noticed when running the test on 380.08: I heard the clicking sound that is fixed in edge. I didn’t hear those in the edge version. It could very well be that the fixes related to eliminating clicking (so the sudden stepper adjustments?) also affect this issue.

When I was running 380.08, I had one vertical 6" path (the side of a square) that refused to run anywhere near F=200, yet all other paths, vertical, horizontal and diagonal ran consistently at F=200. When that problem path was running, motors sounded weird. Weirdness gone now in 412.01 and path cuts at F=200.

cmcgrath5035Staff #

Good grief, my ShapeOko is now demanding overtime pay!
That code does moves a lot, quickly!

AND, rather randomly.

All my runs are from Linux host.
I grabbed your test.7.gcode file.
I edited in a G1 X0 Y0 line at the bottom to make offset determination easier.

This is my tinyG configuration

https://dl.dropboxusercontent.com/u/50261731/PCB%20test/2014-04-20_14.20.50-tinyg.conf

My jerk settings are higher than yours.

Run 1: I ran test.7.gcode using tgFX build 3009.
Run time 4:20
Offset observed (using my definition) was X +10, Y-4 mm

Runs 2,3 and 4

I decided to switch to my GCode dumper script, using plink which is documented in step 5 in this post

https://www.synthetos.com/topics/tests-with-updated-tinyg-and-tgfx-versions-linux-environment/#post-5701

Procedure for runs 2,3 and 4:
1. Move spindle to a predetermined (0,0) point
2. Reset tinyG (thereby set a new X0,Y0,Z0 and, maybe clean up some stored garbage in tinyG(?)
3. execute ./CNC_run
note: I do net get job run time from this script

Run 2
Offset observed X +105, Y -65 mm
During this run, spindle was all over the place (+,+), (+,-), (-,-), (-,+)

Run 3 - just hit reset, then rerun again
Offset observed X +10, Y -68 mm
Motion not quite as off the wall as in Run 2.
This is the log of return info from tinyG, captured by the "Tee" in my script. I have the others, if useful to you.

https://dl.dropboxusercontent.com/u/50261731/PCB%20test/2014-04-20.16.02-file.log

Run 4 - I figured speed was in some way introducing issues, so I made the following simple change to the gcode file with vi:
:1,$s/F2000/F200 , replacing the G1 speed by a factor of 10.
Process was slower for sure, and certainly better behaved than Runs 2 and 3.
Offset observed X-10, Y 0.

So, yes, there is an issue in here with tinyG build 421.01.

Sidebar question: I assume you edited Z movement out of the Gcode file.
Can PCBs actually be cut this fast?

flux #

Great that someone has been able to reproduce the issue :).

Good grief, my ShapeOko is now demanding overtime pay!
That code does moves a lot, quickly!

:) I noticed increasing $xjd and $yjd to 0.05 make it even faster, but perhaps at some cost of precision.

During this run, spindle was all over the place (+,+), (+,-), (-,-), (-,+)

The job never goes to negative, so if you see that, you already know it has gained offset. Btw, the problem can manifest itself with a positive offset as well, though I think I've never seen it with test.7.gcode.

Sidebar question: I assume you edited Z movement out of the Gcode file.
Can PCBs actually be cut this fast?

Yes, I removed Z movement so I can test if faster and more safely without milling anything. I also increased the feed rate from 400 to 2000 to speed up the testing, and I don't think you can actually cut PCBs this fast :). (But I think I will still try what the quality will be when speeding up a bit.)

Related: I managed to finally mill a PCB with the master branch (doing probing by abusing the homing system for determining Zmin; not as nice with the probe where you are able to retrieve multiple points on any direction, not just X), and it seems quite promising!

cmcgrath5035Staff #

flux
I highly suspect that, at least for my case, driver current settings on tinyG are at least some of the issue.

I have never tweaked the pots, since I have not experienced issues like this with prior jobs; I do tend to run them much more slowly.

It is interesting that when I moved all F2000 directives to F200, my results are the same as yours.
In saying same, I acknowledge that the X=10mm offset is an eyeball and ruler measurement, roughly right.

Perhaps there is more than one issue lurking in my setup, such as inadequate current plus what you see as an offset bug (difference between 380.08 and 412.01)

I'll rerun again, with the G0 speed reduced as well in the config file to see what happens.

Here is a question for Alden or anyone else:
Is there any test Gcode with significant quick motion, that can be run repetitively, to assist in determining if a set of recommended digital settings (in config file) plus motor currents actually performs well?

cmcgrath5035Staff #

flux - I generated a pile of data today, will process and post later.
I'll make a general statement that increasing the current to my NEMA 17s did generally improve the performance (lower offsets).

Are you using tinyG to drive the NEMA 23 directly?
How big a difference in current requirement?

Another gut observation - using a DW660 spindle on a machine targeted to the pcb application is likely not prudent. Seems way to much mass being moved about in all directions. Do you have a real heavy spindle? You said you are into Alum plate milling, so I am guessing you have something substantial.
Have you tried something with less mass with the PCB code?

I did not give a lot of consideration to my choice - I have had a DW660 on the shelf for 10 years, finally getting some use out of it.
But after today's session, I'll say that if I get into PCB milling or similar, I'll find a spindle better matched to the task.

I also recall from your config file that your set up has larger travel per rotation on X and Y; larger toothed drive wheel I presume.
Seems that reduces the torque per unit of linear measure, both driving and holding/stopping. Not really what this application needs.

Hard data in a few hours.
No answers, but interesting data.

RileyStaff #

Flux and Grath,

Lots of good stuff here! Flux, could you add your code to the "sending gcode files" on the wiki?
https://github.com/synthetos/TinyG/wiki/TinyG-Sending-Files

Alden/rob/I have been swamped over the past few days. I promise we will look at this. We hear you! I am sorry tgFX did not work in Linux for you. I am very much looking forward to playing with your code too!

Grath you are a machine! Thanks for the help in replicating this issue.

As far as dev goes.. ALL BETS ARE OFF :) That being said here is the "official" game plan. I am getting tgFX stable with "412.01", then we are going to push forward 412.02 as master as there are a few changes from there.

Just an FYI.

I did post a windows bin for the newest tgFX. I will post a new thread there too. I could use some help testing it out. It should address a few of your gripes too grath.

Ril3y

cmcgrath5035Staff #

flux - After running a longish evaluation of my machine, based on your methodology and documented here

https://www.synthetos.com/topics/tuning-a-tinyg-an-alternate-approach/

I went back to your test case, test.7.gcode to see what imporvements I could make with my machine,

I started with F2000 feed rate, pots at 12 o'clock, jerk at 5 Billion, and got similar results to yesterday - drift of x +68, y+53.

Next I moved the pots to 2 o'clock for X, Y1 and Y2. Drift for this run was X -5, y 0 , encouraging
Reran a second time, drift was x +15, Y -3, not quite as encouraging

I tried reducing jerk by a factor of 10 (xjm and yjm at 500Million), similar results with drift at X +3, y -18.

I went back to jerk of 5000 million, reduced to F800. drift x 0, y +10.

As a final test, I set the pots to 3 o'clock, drift was x -3.5, y 0.

All these results are tinyG build 412.01. While there could be a digital fw issue in these newer builds, I am more suspicious, at least in my case, of the mass of the DW660 being just too much for a NEMA 17 shapeOko to adequately control under the workload presented by test.7.gcode.

I'll keep an eye out for other suggestions as they come in.

This is a really interesting test case.

flux #

All these results are tinyG build 412.01. While there could be a digital fw issue in these newer builds, I am more suspicious, at least in my case, of the mass of the DW660 being just too much for a NEMA 17 shapeOko to adequately control under the workload presented by test.7.gcode.

It is interesting that adjusting motor powers can affect the results. Though, perhaps it should be executed numerous times. For example, if it is completely random which moves cause the trouble, then can the results be as well. So there should probably be much more testing, such as running the test with same settings 10 times in a row.

Btw, you should try test.gcode as well, it does significantly less stressful work - and to me introduces significantly less drift, but it does anyway.

The thing that makes me think this is not a machine issue is the fact that master has no trouble with the same machine configuration. Does edge really stress the machine so much harder?

Thanks for keeping on it :). I'll take a look at your approach to calibration when I find the time.

This topic is from the original forum (May 2014). Your reply starts a new discussion linked to it.

Reply

Different problem? Ask a new question

Back to TinyG Support or latest activity.