Forum Replies Created
-
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.
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.
