gcode that produces burning in dogbones about groundcontrol HOT 15 CLOSED

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

from groundcontrol.

from groundcontrol.

@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.

from groundcontrol.

@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)

from groundcontrol.

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.

from groundcontrol.

from groundcontrol.

from groundcontrol.

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

from groundcontrol.

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

from groundcontrol.

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

from groundcontrol.

@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.

from groundcontrol.

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)

from groundcontrol.

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.

from groundcontrol.

from groundcontrol.

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.

from groundcontrol.