But when using smaller holes or fillets, the machine is doing strange things.
I tested so many things, but now i found out that when there are two arc commandos (like G3 and G2) after each other, this makes a problem. It does only the first line and the second arc, it ignores and moves on to the next line. So many times it does the lead in arc, but then it refuses to cut the circle. Sometimes it does, sometimes is doesnt.(See picture)
[attachment file=“110888”]
Can somebody explain and try to help finding a solution?
Also why is it slowing down so much in arcs/circles?
The blue toolpath in Sheetcam means that a rule is being applied. Check to see what that rule is, it’s probably slowing feedrate based on small shape, which is a good thing for small circles. The machine is not rigid enough to keep high feedrates for such small shapes, but most machines have this issue.
On my Lowrider, I have a ruleset that slows feedrate to 60% when hole size is less than 0.5" diameter. Works pretty well.
What gauge material is this and what plasma cutter do you have? 2000 mm/min (~79 ipm) is pretty slow for what appears to be 14 ga? You could either adjust your cut amperage, or speed up your feedrate to get cleaner cuts.
I know most non-machinist software (like Cura) don’t generate G02 (arcs) but they generate a lot of G01 (lines). Sheetcam does not and uses arc commando’s.
I have a hypertherm Powermax 45. Sheet metal is 3mm. The 2000mm/m is indeed slow for this thickness, but i tried with slower feed to check if the machine would do the small circles. I use the settings from the hypertherm manual. I don’t really care about the quality of the cut (i can tweak a lot in sheetcam and i know an MPCNC has it’s limits). But i do care about the right execution of G-code.
That the code is modal or non modal is not the problem, i tried it last weekend but its the same. It’s also strange that the problem only appears at some holes. I will try modality tomorow again just to be sure.
Hrmph… the forum ate my post. Maybe I edited it too much…
I was just reformatting the gcode again because I do that sort of silly thing.
You’re right, though. It’s not every hole. It feels like it’s either a modality issue, or your gcode sender is skipping/missing lines. Are you running anything else on your Repetier Host PC? Is there any reason it would be dropping commands?
Is there anything suspicious in the repetier logs?
The line highlighted red is not a valid command for Marlin’s flavor of gcode. I’m not sure if it’s valid for any machine but I won’t assume.
It appears that the G01 is plunging downward (from Z=3.8 to Z=1.5), and then the G03 is the lead-in, and then the line that starts with “X29…” is supposed to be another arc cut, probably also supposed to be G03.
I don’t know sheetcam, but if you’re experimenting with settings or post, it’s much easier to check if you have any lines starting with “X”. Even if you have to resort to trial-and-error, you should be able to get close without wasting a ton of metal and time.
That’s what he was talking about with modal and non modal gcode. Modal gcode assumes the same command with the new parameters. But if you look at his samples, sometimes it works. Frankly, unless you really, really need to squeeze a few more bytes out of your storage and/or processor, I’d stick to non modal code, and be explicit about each command.
Also, I couldn’t find documentation that Marlin for sure handles modal code.
Marlin does implement modal code in recent versions if compiled with the correct defines set. (GCODE_MOTION_MODES in configuration_adv.h) I also implemented “parenthese” comments for compatibility (enabled with the PAREN_COMMENTS define)
The machine is moving, but here is an new problem. It does the circles, only not is it should. Only one of the Y motors and only one of the X-motors are moving. So the gantry gets twisted by making the holes.Just like the X and Y axis are not cloned.
The outer contour went good.
/Edit: Did some of you tested my code example on your machine?
The “modal” code is quite new and disabled by default, so you code probably won’t work on our machines.
What configuration do you use ? Do you use endstops ? Single or dual ? what controller board/drivers do you use ? how are the steppers linked to it (if no dual endstops, in series ? parellel ? )
if dual endstops are you sure the steppers aren’t overheating ?
Even with GRBL (and bCNC) i had some problems, on small holes, only one of the 2 X en Y motors were running. It looked like the axis were not cloned. So i dug further, and found a solution in sheetcam itself. It’s possible to cut down an arc (G02/G03) in small straight lines (G01).
So when i’m now exporting the code is makes a lot of G01. So the problem whit slowing down in arcs/circles is also solved now. It cut’s on an even speed around the whole contour.
Now, i am going to install the dual end stops to make it square automatically. I want to switch back to repetier, so i took a brand new (so i can switch back easily to grbl) arduino mega (china clone) installed the Marlin firmware on it that i had before. I can connect with repetier (at baudrate 115200) but it is not moving at all when I use manual jog or run a program. Anybody an idea what is causing this issue?
Some progress pics:
[attachment file=111589]
I quickly a tumbler out of a paint can on my lathe. Put some stone in it and let it run about 15min.
[attachment file=111587]
Parts come out very nice.
[attachment file=111588]
When the project is done and working well (easy, nice and quick) i definitely want to share it, so others can use my experience.
I understand you switched to GRBL here but I get similar behavior with Marlin on Rambo with dual end stops (stock from V1 Eng.). Luckily the arcs are very small so not much twist occurred before I found out what was going on.
Would be nice not to have to rely on breaking arcs into small lines… If anyone has a Marlin workaround for this that would be much appreciated.
Interesting thread. I was seeing quite similar behavior on mine while using the laser. G-code created with Estlcam. So the solution lies probably in the G-code generator.
