From the original Synthetos forum (2011–2025)
I will give your shorter test code a try today.
I also agree that any apparent good set of configs (feedrate, currents, jerk, etc) needs to be repeated multiple times to gain confidence.
Your repeatable success with 380.08 vs 412.01 is a mystery to me so far.
And as you point out, moving between them is somewhat painful with parameter changes and checks.
Another brief comment, I used test.7.gcode today as as test case while experimenting with the latest tgFX release, build 3256.
In the course of several runs, I moved my current pots to full on, found that made an incremental improvement in my test case but made no repeatable change in test.7.gcode performance.
In my final run, I set velocity max to 1000 and feed rate max to 200 in both X and Y; extremely slow by your standards. Two runs resulted drifts in the range of 8-10 mm in Y0 final position.
I'll note that the as-drawn output of tinyG in the tgFX window, captured from the status messages, does not display gross offsets or drift, 10mm would be gross for this job..
I believe this says that the servos are not able to properly respond to the tinyG drive signals. Spindle mass is still a possibility, but at these speed settings, plus your good results with 380.08, seem to implicate the servo drive waveforms from 412.01.
Time for Alden to weigh in.
I do note that test.7.gcode has a very large number of relatively short segments(below .1mm), many below .05mm that may not be properly handled, ??
flux - Have you been following this thread?
I reread it today, and note that member grim's reports from post 5719 (midway thru page 2 of the thread) on sound somewhat similar to what you experienced on 412.01 with test.7.gcode.
If I get a chance, I'll give 426.06 a try on my machine.
flux - I can confirm that your shorter test code also drifts on my machine, even with feedrate set to F200. Drift was (1,-1)
I am still running 412.01; Alden seems to have removed 426.06.
Alden - to save you a few minutes, I'll note that this job has an arc made up of 42 sequential 0.028 mm moves, the a few moves later another arc made up of 22 moves, some as short as 0.018mm (both quick looks, not guaranteed worst case).
To me, this is what you were chasing in Z-axis problem.
Here is my version of flux's test case - added lead in and lead out marking with spindle. A Very quick test, you can easily see bad results.
https://dl.dropboxusercontent.com/u/50261731/PCB%20test/flux_short_tes_editedt.gcode
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 :).
flux
Take a look at this Configuration Reference
Specifically, at the end of the document is a section called "Hidden Parameters".
$ML- Minimum Line Segment
Don't change this unless you are seriously tweaking TinyG for your application. It can cause many things to break. This value does not appear in system group listings ($sys)
$ml=0.08 - Do not change this value
$MA - Minimum Arc Segment
Don't change this unless you are seriously tweaking TinyG for your application. It can cause many things to break. This value does not appear in system group listings ($sys)
$ma=0.10 - Do not change this value
What these mean is subject to interpretation, but my assumption on first read a while ago was that linear moves less than 0.08mm ( or arcs with lengths specified less than 0.1mm) would likely fail or cause issues such as your drift.
When I opened your test.7.gcode file, I saw all line segments, no arcs, and numerous line segments <<0.08mm.
I am suspicious that these extremely short segments are at the root of your drift issue.
Interestingly, I cannot get a proper output from my CAM simulator with the test case you just posted, circles.gcode. I may get some time later in the week to try running it on tinyG.
Also, could you clarify what you mean by
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.
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.
I suspect you chose to draw r=1.0mm circles in circles.gcode since many of the PCB pad features in test.7.gcode appear to be r=1.0mm circles or half circles. But what appears to be a secondary cut path in test.7.gcode, perhaps for additional clearance, has many r=0.5mm circles and arcs; those are the ones yielding line segments as small as 0.012 (quick look), <<< $ml=0.08.
Alden will likely be the key commentator here, I believe he is traveling this week so we may not hear from him for a few days.
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.
I am following this thread but will not be able to test until next week due to travel.
The hidden parameters should not affect this. These are internal settings. One other setting you might play with is the chordal tolerance (ct) that sets the length and number of lines used to approximate arcs.
There are internal mechanisms for compensating for the errors in very short lines that should be working in edge. So I might have introduced a bug here.
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 :).
Changes from the dev branch are introduced gradually from 412.03 to 412.10. These may help but the main items affecting positioning are still to come. I'd be interested in your results from 412.10 if you are so inclined, but I would also not be surprised if the results are the same.
flux - very interesting tests and results with segments.gcode and segments-100.gcode. After staring at both, and contemplating how this might relate to $ml and $ma implied precision limits, I started thinking about the problem in digitization space.
My understanding is that, in two dimensions, our machines define an X-Y grid of points separated by travel-per-microstep, the smallest discrete move one can command of the steppers.
For my NEMA 17 machine, that is 36.54/(200*8) = 0.0228mm, for your NEMA 23 machine it is 0.0281mm
So there is always some quantization error in each move, which may accumulate or average out, depending on the internal logic of tinyG.
Add to this "tinyG magic", attempting to fit a third order polynomial to continuous x-y paths to enhance the movement process.
I'll play a bit with your zig-zags.
flux - Thanks, you helped me better understand my problem :)
The fact that these small offsets are accumulating with your test cases is clearly (to me) higher priority for Alden than my one-off error, but I am guessing the mechanism is same or closely related.
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.
I noticed that pcb-gcode also has the parameter 'epsilon'. It was originally 0.00254 and I raised that to 0.05 with high hopes :). Sadly the resulting G-code still causes a drift. But at least it runs faster with the F2000-speed (obviously not the speed I would eventually run it with).
It's quite possible the epsilon=0.05 still leaves some short moves, or even many. Even though the random peek only showed some 0.15 mm moves, there might have been others, and I didn't verify the generator if it always uses its 'are points close' test.
flux - I got the impression that your original short test.gcode was a path extracted from test.7.gcode.
That short path had some very short segments in it, if you want to focus on that path for the evaluation of 'epsilon' impact.
In fact, looking at test.7.gcode in my simulator, there seemed to be a lot of discontinuties and "sharp" corners, obviously smoothed out somewhat by the gcode generation process.
This topic is from the original forum (May 2014). Your reply starts a new discussion linked to it.
Back to TinyG Support or latest activity.