Boy, this gcode is much more complicated than I expected for cutting a square.
It is doing a lot of movements at the corners, but basically, I can tell that it is cutting a straight line, about 26mm long, in both X and Y. So that isn’t going to be the problem. It should be 25.4mm+the bit diameter-whatever round over it’s doing at the corners. So that’s close enough. gcode checks out.
So take a step back. Can you just move the gantry with a command and see how far it goes? Like have it move 100mm in the positive X and then measure it with a ruler? And do the same in Y.
I’m about to go to bed, but I’m sure whoever jumps in next will be able to tell what’s wrong from how far off that value is.
Also, send a M503 command, and look for the line that says M92. Mine looks like this (on a printer, my LR is off):
Was able to get out to the shop a bit early this morning. @jeffeb3 I was able to run the test you suggested. I ran 4 lines, two with the controller and two with repeteir. First test was in the x+ position. Second in the x-, third y+ and last y-.
All. Moves were 100mm. Both through the controller and rep. When moved from either, both measured 120mm. This was the same for all four test.
After each test I ran the m503 command and all read the same 100, 100, 400, 100.
I agree with @jeffeb3, that the gcode looks reasonable. The first bit has straight line segments that appear to be 28mm in x and 26 in Y, but later (finishing pass?) it is 25.4mm in both axes. I don’t see how you could get a scaling error in the gcode, unless the gcode is generated in imperial units and interpreted in metric or vice versa. That should result in a MUCH larger scaling error (25.4x).
It looks like you have a 20% scaling error, based on the 100mm travel test. I think the firmware “Steps per Unit” setting is the likely place for a scaling error like this to originate. Perhaps try reducing steps/unit by %20?
PS, Having recently seen the new Star Wars movie, I wonder if I should now refer to “Imperial” units as “First Order” units… 8^) I’m such a geek.
I have went into the firmware and reset my steps. Not a big deal. However, somewhere between post process and loading the file into repetier, (which I just un-installed and reinstalled) still produces double the size of my designs. I even loaded my last successful file, and it is doubled as well.
I don’t THINK the print bed dimensions would cause this, but I’m actually not familiar with any part of the tool chain in use. Other may be more help.
My best guess, though, is that somewhere in the process the number of steps generated per unit is getting doubled. If the steppers were stepping at 1/8 microsteps instead of 1/16 that would do it too, but I think that would show up when just jogging the machine around too…
The gcode looks OK, so the problem would appear to be somewhere “downstream” of that point.
I went back through the firmware for the past 2 hours. Here’s what I came up with… … nothing. Reset the firmware to @jeffeb3 original, adjusted my endsstops, resized my bed. Flashed firmware. Problem solved. At least for now.
A quick tip to debug issues like this is to use a file comparison tool to compare your firmware with a “known good” version to see what you may have changed to cause the issue. This is a great tool to have:
