gcode that produces burning in dogbones

[mindeye]

Unfortunately, this version was designed and cut using 3/16" bit, so I hope you have one kicking around. I still need to re-test it with the latest firmware / GC. The gcode is just one of the 3 inch by 3 inch end pieces, it's designed with a 3/16" thick radiata pine 3-ply in mind. It cuts it in a single pass but the dogbones end up burning because the bit stays near them for way longer than the normal sides.

If for some reason you don't have a 3/16" bit, I've also included the svg and if you scale it up a bit, I suspect it will work just fine with a 1/4" bit too. I believe I used a feedrate of 25, cutting the whole depth at once using a 2-flute spiral upcut endmill since it's only 3/16".

electronics-cover.zip

[mindeye]

So just re-tested with latest firmware / gcode and same result. I suspect you could use any size bit with the gcode and it would repro the burning since it's mostly because it hangs out in the same spot for a long time.

Pic: https://drive.google.com/open?id=102MDDFPUCvhLECd8Yh1cBZ8SqguBB8dK9A

Video: https://goo.gl/photos/UMW3pdWhQxp6qmtb6

[davidelang]

I haven't looked at your g-code, but is there any chance that it's doing something like a tiny circle at the dogbone instead of just a diagonal out and back? One thing with the way the maslow processes g-code is that it processes the g-code one line at a time, so if you have lots of short movements, it takes it as long to decode the short movement as it would a long one. So if it does a circle as a lot of tiny line segments, it will be very slow. If it can send an arc command (that the maslow firmware converts to a lot of tiny line segments), it will be much faster as it doesn't need to pause and decode each command.

[BarbourSmith]

My guess would be that @davidelang is right that the issue has to do with processing many lines of gcode slowing the machine down. Let's investigate further. This might be a good excuse for speeding up the serial protocol.

@mindeye Thanks for testing with the newest firmware also, very thorough. Taking multiple passes will likely help with the burning because the bit is in less contact with the wood, but the real fix is to insure that we are getting constant tool speed through corners.

[davidelang]

Ok, I zoomed in on this in the svg and it is indeed making the dogmones by describing a tiny circle. I'll bet the circle is the diameter of your bit, so as it goes to cut 'around' the inside of the circle the bit is not moving at all try re-doing the svg so that where the dogbones are, you just put a small 45 degree line from the corner into the material for 1/2 your bit diameter. you may have trouble running this through the g-code converter as it won't like to cut something so narrow, but try it. some g-code converters will have no trouble with it. David Lang

[davidelang]

looking at the g-code, look how many statements there are that are +- 0.01" of each other (I'm assuming these measurements are in inches) for 62 lines of g-code it moves: x ranges from 2.3231 - 2.3278 a range of 0.0047" Y ranges from 3.209 - 3.2143 a range of 0.0054" including several places where it doesn't move at all for 3-4 lines G1 X2.3231 Y3.2143 G1 X2.3256 Y3.211 G1 X2.3261 Y3.2103 G1 X2.3261 Y3.2103 G1 X2.3261 Y3.2103 G1 X2.3264 Y3.21 G1 X2.3266 Y3.2098 G1 X2.3266 Y3.2098 G1 X2.3267 Y3.2096 G1 X2.3268 Y3.2094 G1 X2.3271 Y3.2087 G2 X2.3274 Y3.21 I0.0909 J-0.023 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.3272 Y3.2108 G1 X2.3272 Y3.2108 G1 X2.3271 Y3.2113 G1 X2.3271 Y3.2113 G1 X2.3271 Y3.2113 G1 X2.3269 Y3.2109 G1 X2.3268 Y3.2106 G1 X2.3267 Y3.2104 G1 X2.3266 Y3.2102 G1 X2.3266 Y3.2102 G1 X2.3266 Y3.21 G1 X2.3266 Y3.2098 G1 X2.3266 Y3.2098 G1 X2.3265 Y3.209 G1 X2.3268 Y3.2094 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.3276 Y3.2108 G1 X2.3276 Y3.2108 G1 X2.3278 Y3.2113 G1 X2.3274 Y3.211 G1 X2.3272 Y3.2108 G1 X2.3272 Y3.2108 G1 X2.327 Y3.2107 G1 X2.3268 Y3.2106 G1 X2.3265 Y3.2105 G1 X2.3266 Y3.2102 G1 X2.3266 Y3.2102 G1 X2.3264 Y3.21 G1 X2.3261 Y3.2096 G1 X2.3266 Y3.2098 G1 X2.3266 Y3.2098 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.3274 Y3.21 G1 X2.328 Y3.2106 G1 X2.3284 Y3.2109 G1 X2.3276 Y3.2108 G1 X2.3276 Y3.2108 G1 X2.3274 Y3.211 G1 X2.3271 Y3.2113 G1 X2.3271 Y3.2113 G1 X2.3264 Y3.2118 G1 X2.3231 Y3.2143 G1 X2.3182 Y3.2181

[davidelang]

what software did you use to convert this svg into g-code?

[davidelang]

try this .svg to base things off of (and try the .nc file, but only with the bit well clear of the workpiece, I have zero ability to test if it came out right)

endplate.zip

[BarbourSmith]

It's good to see that the core issue is probably some funky gcode, but at the end of the day we should be able to handle funky gcode. I think that there are two ways we can handle this. 1) We can speed up the rate of gcode processing to the point that even if there are 60 lines in a row which don't command real motion, they are processed so quickly that we don't notice. 2) We can just ignore lines which don't cause any real movement on the Ground Control side.

Option 1 is the right way to do things, so lets try that first, then if we hit limits on how far we can push the execution speed, we'll look into option 2

[mindeye]

@davidelang This was just sketchup -> svg -> makercam. @BarbourSmith sounds good to me! In the meantime I think I'll just keep using my 45 degree offset squares since they mostly work.

[davidelang]

@BarbourSmith more efficient and faster gcode processing is always a win, but at some point we will hit the limits of the arduino processor.

I suspect that the overhead of processing the gcode (transferring and interpreting it) is the limiting factor here, so trying to detect in the aruduino that the move doesn't matter is too late.

Creating a "g-code lint" program that we could run on windows/linux/osx that would go through the gcode and flag commands we don't understand, or ones that don't move enough to matter would be a useful tool (and give people a way of checking the g-code without actually truing to machine something)

[davidelang]

@mindeye the root of the problem is that the svg is drawing a circle segment (12 short line segments), doing as narrow a rectangle as you can get (2-3 line segments, in my svg it's a straight line in and out) will work far better.

[mindeye]

Has this been fixed? I noticed yesterday that what was essentially drilling a hole but instead was something like 30 infinitesimal movements per z-step didn't end up burning anything and GC seemed to fly through a ton of log statements incredibly quickly. (just to be clear, my intent is saying that maybe this can be closed, not that it's urgently needed)

[BarbourSmith]

I've done some things to improve the speed, but I think I can do even more.

The way it works now is that a line is sent, decoded, executed, then the next line is requesting.

The circular buffer I added last week means that the firmware can hold several lines in memory which would let us have 2-3 lines buffered, maybe a few lines which have been decided stored in memory, and the one line which is being run.

It gets a little tricky so I want to add it carefully but I think we can get 2-3 times better performance than we're seeing now.

I appreciate your trying to keep an eye on closing issues which aren't a problem anymore and I think you are right that we're getting closer. I'd vote to leave the issue open as a reminder that things can get better.

[only1pj]

Would buffering multiple long lines of code, which result in cutting a complicated/intricate part, result in the lines being truncated and causing problems with the gcode?

…

On 21 April 2017 at 16:30, BarbourSmith ***@***.***> wrote: I've done some things to improve the speed, but I think I can do even more. The way it works now is that a line is sent, decoded, executed, then the next line is requesting. The circular buffer I added last week means that the firmware can hold several lines in memory which would let us have 2-3 lines buffered, maybe a few lines which have been decided stored in memory, and the one line which is being run. It gets a little tricky so I want to add it carefully but I think we can get 2-3 times better performance than we're seeing now. I appreciate your trying to keep an eye on closing issues which aren't a problem anymore and I think you are right that we're getting closer. I'd vote to leave the issue open as a reminder that things can get better. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#158 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZiI7Xx_dbJlHN2s1WMC2rTIClYhTvQks5ryMuJgaJpZM4MtuTk> .

[BarbourSmith]

Great question. We're using the same protocol as grbl so the buffer is 127 characters. The number of lines you can fit in the buffer fluctuates based on how long each line is.