We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
Shapes weren’t cutting right. So I’ve made a few test squares and measured them. A 100 mm x 100mm drawing comes out at 97.8 x 99.2. (Slight variations on these figures over many tests, but around that size)
I know from reading through this topic that v wheels and belt tightness is the most likely issue here - but I have spent hours (literally!) tweaking the v-wheels (no play at all, but the carriages can still be pushed) and the belts are twangy tight. So I really don’t think it can be that.
I have also turned up the x and y pots - y is almost at it’s max.
What do you get when you cut a 100mm square?
Any suggestions? Could it be my browser? (Seems unlikely but it came up on another thread.)
thanks guys. That was interesting alright. Here’s the thing though -
Before I changed the calibration code I did another test. I set the nudge/step to 700mm and hit the x controller. It didn’t quite get to 700 - more like 699 - but not bad over that distance.And it returned home exactly. On the Y it went to 698.
If it had behaved as it did when cutting the 100mm square, it would not have got anywhere near as far.
So it seems that the callibration may be out - but not by enough to explain the initial problem…
If you run that same test 10 times in a row do you get the same accuracy? If so then it must be a problem related to how the motors/belts/pulleys are behaving when under load.
Try to cut a 100x100 mm square again with the feed rate very slow and the DOC at .01 (just to mark the wood) and see if the square is correct,
Yes, that makes sense, Allen. But when I tried that the size came out as before - 99 x 97. So what does that tell us?
In the meantime I tried other test shapes - small curved pieces. The curves were flattened and a nick/indent appeared in one side. I’m beginning to think it’s a software problem. I generated the square directly in Easel, and the earrings cut-outs are imported SVGs. They all look perfect in Easel. Could it be that it isn’t sending the right instructions to the x carve?
(I downloaded another browser too - it didn’t make any difference.)
A software issue like that is pretty low on the likely hood scale. It is much more likely a hardware/electrical issue.
If you power down the controller and move the carriage by hand in in X and Y directions does it move easily/smoothly over the entire length of travel? ie no rough spots or binding.
Have you checked all the eccentric nuts to be sure the vwheels that are attached to are snug against the rail (it should be difficult to turn the vwheel with your finger, but not so tight that you have trouble moving the carriage by hand.
Also check that your belts are tight and that your set screws on the pulleys are tight
Tim
Is it possible to open your Gcode file in word pad. Take a look at the code and see if the moves give you the square you are looking for. You sould see a lines that read something like this.
G0 X0 Y0
G1 X100 (plus the dia of your end mill)
G1 Y100
G1 X0
G1 Y0 (You are now back to 0,0)
There will also be spindle speeds, feed rate, Z numbers for DOC etc You are interested in just the X and Y moves and if they work out to the distances you want the machine to move plus the diameter of your end mill. So if you have a 3mm end mill the move should be 103mm etc.
The gcode from Easel is not what I expected to see, but I drew a 100mm x 100mm square and generated the gocde and it is exactly what you have. I am not a gcode expert by any means but I would expect to see the x value old steady while y increases then the y old steady while x increases etc to draw a simple square. Instead X and Y are changing on every line. I need to figure out what it is doing,
OK, the gcode is not doing a profile (cut on the edge) but a pocket (fill) operation so it is moving the cutter in ever larger squares starting at the middle of the square. I should have figured that out sooner
So the gocde is fine.
I would recommend changing your test to just do a 100x100mm square profile cut the same depth as the depth of cut you have selected so it only makes one path around the square.
I started a new project, drew the square, selected ‘outline’ and ‘outside’ - all just the same as the first time. And got the same results. Which, as you say, doesn’t seem right, does it? It shouldn’t need all those lines. But it does cut an outline only, outside the 100mm line, just not accurately.
(Then I changed it to fill, generated the code and counted the lines of code - 1896!)
Just for kicks and giggles, try removing the power wires for the spindle from the drag chain and keep them well away from the stepper wires and test it again. I’m thinking electrical “noise” from the spindle may be jumping from the spindle wires to the stepper cables. tweaking the step count just enough to give you heartburn. It wouldnt be the first time.
If you position the tip of the bit (with power off) just above the left side of the square you just cut and then have Easel jog X 100 mm to the right does the tip of the bit wind up directly over the right side of the test square?
Is it possible to hand code for that 100mm square. If you can load Gcode that has been hand coded then you would see if it is something that Easel is doing or something the machine is doing to cause the square to not come out at 100 X and 100 Y.
That is some strange code. For a single pass from 0,0 around the square and back to 0,0 should be no more than 6 lines of code.
