Home › Forums › TinyG › TinyG Support › Slowing down at the end of a long job
- This topic has 4 replies, 3 voices, and was last updated 10 years, 4 months ago by
alden.
-
AuthorPosts
-
July 10, 2014 at 6:12 pm #6382
Gianteye
MemberI’m developing a plotter and I’ve noticed that when I run a Gcode file with a lot of line segments (like for a cursive font) through TGFX it will slow down towards the end to the point where I can hear an audible pause between line segments. If I run another job right after that one it’ll move just as slowly. Forcing TGFX to quit and restarting it seems to clear the problem, but I’d like to find a more sustainable solution.
I ran a test with a few circles made of line segments at different scales with different subdivision levels. The speed really started tanking when I had a tiny 1/8″ circle made up of 250 line segments.
Has anyone else experienced this? It doesn’t seem to be the planning buffer overflowing as it doesn’t fix itself when a job is finished and another one is queued. Adjusting the jerk settings doesn’t change the behavior much. I suppose cranking the speed way down might correct it, but any speed below 500mm/min will make the pens I’m using bleed visibly and wreck the writing.
July 10, 2014 at 8:05 pm #6385cmcgrath5035
ModeratorSome info about what versions your are running would help.
TinyG build ?
tgFX build ?
Perhaps post your system configs to a text file and post a link.Depending on your machine (mm/revolution), a 1/8″ circle with 250 segments may have segments too small to create moves.
July 10, 2014 at 9:05 pm #6388alden
MemberWe think this is tgfx; a limitation in the JVM where garbage collection kicks in. The equivalent of a memory leak. I would not expect the behavior to change by adjusting the TinyG board. I don’t think the problem is there.
July 11, 2014 at 6:57 am #6398ModeratorGianteye
It would seem a helpful test would be to send your Gcode to your tinyG via an alternate sender. Do you have Coolterm loaded to on your control computer? If you are running Windows, you might install JCNC and try that. Or try the ChilliPepper interface.If my math is correct, a 1/8″ diameter circle in 256 segments has a segment length of approx 0.0195mm. A 45 degree angled segment would call for relative x and y moves of 0.0138mm. Other angled segments will call for smaller x or y moves. These are likely too short for a ShapeOko setup. My understanding is that tinyG accumulates moves it can’t make until it can make a move in that direction.
But I seem to recall you have built a screw machine with better mm/revolution precision.Alden has evaluated short move dynamics for the 435.10 tinyG build down to about 0.02mm for a ShapeOko.
ShapeOko with NEMA17s are typically 36.54 mm/rev, or 0.023 mm/microstep (for X and Y)
Your expected minimum move would then be about 0.02*YourMMperRev/36.54All this math is of course moot if the issue is in tgFX.
But always good to have in mind the maximum precision of moves for your machine, which is the distance moved with a microstep.July 11, 2014 at 8:31 am #6400MemberThe other factor in the equation is the chordal tolerance selected ($ct). This is defaulted to 0.01mm. https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#ct—chordal-tolerance
The shortest move is actually a function of execution time, not line distance, although moves that are less than one step at the microstep setting cannot be executed. The 0.02mm lower limit is assuming a high velocity G0, for G1’s and arcs the lower limit may be lower depending on your machine config and the feed rate specified.
If a move is detected that cannot be drawn the system preserves the current location and starts adding the short gcode moves together until it accumulates a move that’s big enough to execute. In an arc this has the effect of reducing the number of arc segments at the board level.
-
AuthorPosts
- You must be logged in to reply to this topic.
