June 5, 2019 at 3:01 pm #102672
I’ve noticed something peculiar in my first cut: There are jerky movement in two of the corners of a simple square. You can see that they happened not in the part but in the remaining material (see attached pictures).
Here is a dry run without load where you can also see the jerking (around the 12 seconds mark – 1st corner and the 34 seconds mark – 4th corner). They are very quick movements and consistent in all four paths.
My setup is:
- RAMPS stack with the latest Marlin Version from the Allted/Marlin GIT repository from a couple of days ago. (MPCNC_Ramps_T8_16T_LCD_32step_DualEndstop) The only adjustment I made was for dual Z drive instead of Y, obviously.
- EstlCAM 64bit Version 11,113, configured for “Marlin” with G02 and G03 arc commands and relative I/J coordinates (as per the instructions here).
- A 100mm square drawn with Inkscape
- Ran the GCODE from the SD card.
I don’t have a lot of experience with GCODE so I can’t tell who’s at fault here but it looks to me like Marlin does not correctly handle two of the four corners. That would explain a lot of things, in fact.
I’m suspecting Marlin, because the tool path looks OK in Repetier Host… Should I deactivate the arc commands? Would I pay a high price for that in smooth operation or compatibility?
The GCODE should be safe for anybody to run who wants to test it out, as long as you have at least 2omm clearance on the Z axis and 100 x 100mm in the plane.
Attachments:June 5, 2019 at 4:59 pm #102691
Try it without arcs, as they are in your code, but should not be for a square. So I am assuming rounded corners? Se what happens run it in the air to do a quick check.June 6, 2019 at 11:04 am #102729
I tried without the arcs and the result is now as expected: No strange behavior in the corners.
So, it looks like there is something wrong here: At least my EstlCAM’s “Marlin” preset produces GCODE that Marlin 2.0 cannot interpret correctly in some cases. (As, for some reason, it worked fine on the other two corners.)
I’m happy to have a solution now but still would like to understand: Are there downsides such as less smooth operation or compatibility issues?
(BTW: They are sharp corners in the part but in its default settings, EstlCAM is rendering them like the attached detail – with a quarter circle around the corner point).
Attachments:June 6, 2019 at 3:56 pm #102759
I actually think that is my fault, some of the settings need to be tweaked in the firmware but I am having a hard time coming up with definitive tests for all the little settings.June 10, 2019 at 1:00 pm #103036
OK, now I know what is going on: Is it correct behaviour that my Lowrider simply ignores all GCODE lines that would send it into either negative X or negative Y?
Because that is what it does and that is why my test cuts are under dimension: My origin is on the corner of the finished part, so the two sides that make up that corner are cut ON the outline of the part (rather than around it).
I’ve noticed that this is also the behavior when using the LCD (and I find it quite annoying) but I did not expect this to be enforced for GCODES as well.
If this is indeed the intended behavior, please be aware that it is not safely implemented for G02 and G03: When trying my cut with arcs, I saw the machine jump into negative territory.
Attachments:June 10, 2019 at 3:17 pm #103051
I am not sure what you are asking. It typically stops at 0 and doesn’t move further, it does not ignore them.
If it does go past with arcs than yes that is a bug.
You must be logged in to reply to this topic.