TinyG edge drifts on series of small movements

Hello again,

I’ve now seen the problem occur on the master branch as well.

I’ve replaced the X-belt, lowered the motor currents to the default twelve-o’clock-orientation and lowered the jerk values. But this test case still drives makes both my X and Z drift, X by around -19 mm and Z by around -1 mm. I tried both keeping Z power management on and off, no difference. I had also reduced Z jerk significantly and reduced its maximum speed, with no difference.

Here’s the test case: http://www.modeemi.fi/~flux/tinyg/circles.gcode

And here’s my current configuration: http://www.modeemi.fi/~flux/tinyg/tinyg-settings-2014-04-27.txt

Summary of the test case: radius 1 mm circles made clockwise and counterclockwise in 2 mm pattern, and a small drilling made to the center. The perl script for generating this is at http://www.modeemi.fi/~flux/tinyg/generate-circles .

I wonder, do you see the same issue with edge? I ran it with actual PCB (twice, with identical results), but you could just run it in the air. It takes about 20 minutes to run on my settings.

I did now notice that I had not started my fan for cooling down the bottom of the TinyG board, and I will do the test again (in air, this time) with the fan, but decided to post this before anyway. I did have the fan on on the first test.

I actually also took a video of the operation, and nowhere did I see anything out-of-the-ordinary.. So it just seems it drifts a little bit at a time.

I hope something can be found to explain this, I cannot quite understand what is going on :).

Hi!

Yeah, I’ve read about these parameters, but it’s difficult to say about their real meaning. I imagine they should not make it impossible to make shorter lines than the values indicated though and I didn’t touch them, as they suggest not to do :).

But this actually does give me a test case idea: Just do a 1000 0.01 mm moves to a certain direction and look what it does!

Well, I did it, and no drift occurred, but then I gave it a twist and behold, here is a test case that introduces an about -4 mm horizontal drift by doing a small zig-zag-pattern (increments Y by 0.01, but X increments from 0.00 to 0.03 and then back to 0.00): http://www.modeemi.fi/~flux/tinyg/segments.gcode (and the generating script: http://www.modeemi.fi/~flux/tinyg/generate-segments, run it with argument 10). It takes about 20 seconds to run on my settings.

However, doing the same test scaled by factor 10 still exhibits the same error, and now we’re talking about movements that are at least 0.1 mm long. It actually introduces an even bigger drift. The 10x scaled test case is here (produced with argument 100): http://www.modeemi.fi/~flux/tinyg/segments-100.gcode . It takes about 1 minute 14 seconds to run on my settings.

Btw, circles.gcode does not do very small moves, unless TinyG internally splits the relatively small arcs into such short segments, which I imagine it does 😉 but I imagine it would also respect such parametrized limits.

About the visualization: does your visualizer support arcs? Not all seem to do. At least OpenSCAM does show the circles.

I’ve considered about writing a converter that would replace those extremely short lines with slightly longer ones (by removing intermediate moves), it is doubtful I would need that kind of precision, but the segments-test case suggests to me that it might not help. And per circles.gcode, perhaps replacing the arc-forming segments with actual arcs would not help either.

Are you saying that you actually cut PCB copper, twice, with circles.gcode and the results appear to be A.; cut without drift, yet the final X0 position is offset by -19mm or that the two runs are B.;the same, showing accumulated drift error as the cuts are made? I am assuming your answer is B.

B: the circles are cramped horizontally, and in the end I can see the X has moved (also Z, so the cuts get deeper and deeper gradually); I must assume the X just gets drifted continuously, making the circles cramped.

• This reply was modified 10 years, 7 months ago by flux.

No hurry, have safe traveling :).

I took a look and I take it it’s 412.10 that has the fixes you are talking about? The most recent edge I had tried before was 412.02.

I’ll try the new edge before you’ll get back :).

Hello!

I tried 412.10 and it worked great for the segments.gcode, segments-100.gcode and circles.gcode.

However, test.7.gcode tripped it: X offset around -4 mm and Y offset around 12 mm :(. (Of these tests only circles.gcode exercise the Z axis.) I also tried the latest edge (412.11), it behaved identically.

When running test.7.gcode there were segments when it was moving reaaally slow (50 mm/min?), not trying to accelerate to 2000 mm/min at all even though it looked to move directly or almost directly to some direction. Then again some of the round segments sounded like it was accelerating and decelerating for each of the small segments and maintaining pretty good speed doing it. (200 mm/min? These are purely guesses.) test.7.gcode contains no arcs, only very small segments, so perhaps a post-processor could serve as a temporary workaround, as the other tests worked ok.

I also had to modify my uploader, otherwise it would not proceed after the first circle (or arc) in circles.gcode.. Apparently it doesn’t do the queue report always? It started to work again after I dropped the ‘qr’ limit to 2 in my program (it used to be 20) so basically it’s uploading respecting (or not..) the rts/cts. There is even this (closed) issue https://github.com/synthetos/TinyG/issues/66 about it, dunno how it worked there as I can see it’s not reporting qr > 3 after an arc (or two).. It only responds with qr:3 or qr:4 during my test.

• This reply was modified 10 years, 7 months ago by flux.