i’m trying to send gcode to my uArm Pro. In general it works great but there seems to be a problem in the evaluation of G2 and G3 (move in an arc).
For example this code:
G01 X242.565913 Y-30.160479 F100.000000
G03 X242.738369 Y-29.972835 I27.789266 J30.048330
should move the arm and then create a very small arc with constant z-axis. I think the arc it starts is correct but it never stops moving (until i cut power because the arm is near its max. range) and even slowly moves up (z-axis in positive direction).
Is this a know issue and is there a possible workaround?
Ahh, found the issue, it was on my side (of course)…
I used inkscape + a plugin to export some gcode, but had to switch the axis, forgot to also switch I/J, so the center-point of the arc was completely miss-positioned…
Still, the behavior is wrong!
A very simple example to reproduce the issue:
move arm to 250/0: G0 X250 Y0
draw a full circle around 260/0: G2 I10
Instead of drawing a circle in front of the arm (around the y-axis) the arm moves away left (negative y-axis) in a wide arc. I guess there is an (internal) problem calculating the center-point of the arc (which is probably done on polar coordinates). Could you check that please?
Hi there, thanks for your feedback. The axis of uarm swift pro is based on the industry robot so it’s a bit different from the inkscape. And I have reported the internal problem to our engineer. Thanks!
It is interesting to compare the marlin-based firmware for uArm to the most recent version of marlin. These commands were completely changed around since the 1.1.0-RC8 version that the uArm pro firmware seems to have been forked from. I have been exploring this as a possible avenue to fix the issue, but its nice to know its officially recognized now.
Until then, have you considered using the “flatten path” inkscape plugin to convert the svg args into a series of line segments? I have been using this to continue making progress until the arcs are fixed, and the results have been generally successful so far.
Thanks for pointing me to flatten path, didn’t know about that. So far I was just crossing fingers that the gcode-plugin creates arc-paths short enough that I can remove I/J without big visual impact (but that won’t work for big, perfect circles) - results are quite nice.
I guess the changes they applied so far are not in a state where you could port them to newer Marlin-releases easily… But I did not check, yet, just hoping to get this fixed soon.
Ohhh, took some minutes to check the code.
Unfortunately this is more tricky than it seems, as the ufactory-guys have some strange way to add their “hacks” to Marlin and I instantly found multiple issues
G2/3 do not trigger the internal hack that enables the laser. As I saw it burning, I guess there were some updates in between the latest push of the source to guthub and the current firmware.
Moving relatively with M2204 does switch to absolute positioning always, even if relative-movement–mode was selected before.
@tony: can you please ask your guys to push the latest code, I try to help with the issue, but I cannot do that on the publiched version, which is obviously outdated.
In general, I would recommend you to bring as many changes as possible to MArlin upstream, will save you a lot of maintenance work!
The problem is located in the replaced version of line_to_destination(). While the original code just adds a line to the planner, the uarm-version also do the calculation for the kinematics / coordinate system. This works fine for G0/G1.
Problem is the code that segments the arcs (plan_arc) is directly adding the line-segments directly to the planner. I did not have a chance to test on the device, but it should be enough to preserve the final destination and to replace the calls to planner.buffer_line by setting the intermediate destination and calls to line_to_destination
