Print moves very slow, gcode generated with inkscape

Hello, I am developing a pen plotter and using inkscape's photonics extension for laser cutters to make gcode files. The machine is moving very slow and I don't know where to check, I have found my ideal feedrates and the machine moves fine when I send it G0 or G1 commands, but the gcode of a random sketch that I do in inkscape, which is mostly G2 with four decimals (no idea if that makes a difference) is unusable. The speed is simply too slow. Where should I check first? Travel speeds seem to be fine, my guess is that it has something to do with shorter segments and that their size makes it hard for the thing to reach its acceleration. How is jerk involved in all of this? thanks.

Edit: I forgot to mention. The machine is 200 x 200cm, It's very big. I don't know if there is a parameter out there that maybe is intended for the smaller sizes of 3d printers and that at this scale has to be adjusted. No idea, just another thought.

Edited 1 time(s). Last edit at 06/01/2020 11:41AM by acastles91.

Look for F parameters in the G01 commands in the gcode file. Those set the speed in mm/sec.

If you want it to plot really fast, dump the steppers and switch to servomotors. Here's my 1m x 2m sand table erasing a pattern at 2000 mm/sec, acceleration 15,000 mm/sec^2:

[vimeo.com]

It is pretty simple to convert from steppers to servos. The motors with integrated drivers cost about $100 each, shipped from China.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

Might mention which firmware and hardware you are using:

• The configuration isn't identical across all firmware
• I understand second-hand but do not know that arc/circle (G2 and G3) processing can be slow on slower processors, and here you benefit both from 32-bit processors and from higher clock speed

Might consider posting a representative snippet of the generated gcode, rather than just describing it.

Thank you for replying. I have tried the F parameter and it does work as it should, it moves quickly. But when it reads a g-code file and not a command that I input directly, it moves very slow when it comes to executing G3 and G2 commands as far as I can tell. The g-code generator that I'm using casts a G1 F10000 (which is the limit I found for the feedrate) right before the G2s and G3s, and this should set the feedrate for the following movements, right? Is the feedrate of G2 and G3 movements, different than the one of G1s and G0s? I think it has to do with the length of the segments of the path, do you think it might have some relevance? Very nice machine you built, congratulations! I would like to see more. Can you share the link to the servos you used? Thanks again!

The F parameter is modal, which means it stays in the system until something changes it, so theoretically it should apply to G2 and G3 moves, but the controller you're using may be the limiting factor. G2 and G3 are computed moves and the math takes time.

Here's a bunch of info on the servomotors I used (iHSV42-40-07-24): [drmrehorst.blogspot.com]

You can see the mechanism here: [vimeo.com]

More of the sand table: [vimeo.com]

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

Good to know that it's modal and it works like that, thanks! The controller is a SKR1.4 with Marlin 2.0, which works with a 32 bit chip, so I don't think the problem is there. Something strage about the g-code, is that every coordinate has 4 decimals. I don't really need that precision, is it maybe part of the problem?

You aren't the first: [reprap.org]

Since you are are using Marlin, post your ARC_SUPPORT configuration, as well as your CLASSIC_JERK or JUNCTION_DEVIATION configuration. That's the minimum for anyone else to be able to say anything meaningful about your Marlin build and G2/G3 really! And do post a representative sample of your gcode.

Make sure you have read: [marlinfw.org]

TDD, you are running that off a duet running RepRapFirmware, right? Does the sandify output use G2/G3?

I believe that RepRapFirmware can be built for that SKR 1.4 board: [www.jayuk.org]

See [duet3d.dozuki.com] for G2/G3 on RRF

You could also try Klipper and do all the motion planning on an rPi; I believe it also supports the SKR 1.4.

Lots of options to try!

Yes, Duet WiFi. Nope- everything coming out of Sandify is G01 commands.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

Thank you all for your answers. Here is a fragment of the g-code that I'm trying to print, which runs very slow:

M107 1 S0

G90
G21
G1  X1273.0515 Y1665.2401
G4 P0 
M106 1 S1
G4 P200
G1 F10000.000000
G3 X1272.0575 Y1657.0319 I159.3581 J-23.462
G3 X1271.5225 Y1648.6104 I133.8019 J-12.7281
G3 X1271.3691 Y1632.7133 I358.035 J-11.405
G2 X1271.4675 Y1617.014 I-1251.8396 J-15.6993
G1  X1271.4675 Y1602.0473
G2 X1271.4019 Y1588.4518 I-1408.7268 J0.
G3 X1271.4915 Y1575.4398 I393.4214 J-3.7971
G3 X1272.3357 Y1562.3419 I159.5654 J3.7078
G2 X1273.0522 Y1548.8323 I-128.1889 J-13.5729
G3 X1273.6029 Y1537.9284 I108.2177 J0.

The board I'm using is a SKR 1.4 with Marlin 2.0. Here is part of my configuration:

#define ARC_SUPPORT               // Disable this feature to save ~3226 bytes
#if ENABLED(ARC_SUPPORT)
  #define MM_PER_ARC_SEGMENT  0.0   // Length of each arc segment
  //#define MIN_ARC_SEGMENTS   24   // Minimum number of segments in a complete circle
  #define MIN_ARC_SEGMENTS   0
  //#define N_ARC_CORRECTION   25   // Number of interpolated segments between corrections
  #define ARC_P_CIRCLES         // Enable the 'P' parameter to specify complete circles
  #define CNC_WORKSPACE_PLANES  // Allow G2/G3 to operate in XY, ZX, or YZ planes
#endif

////////////////////////////////////////////////////////

/**
 * Default Jerk limits (mm/s)
 * Override with M205 X Y Z E
 *
 * "Jerk" specifies the minimum speed change that requires acceleration.
 * When changing speed and direction, if the difference is less than the
 * value set here, it may happen instantaneously.
 */
#define CLASSIC_JERK
#if ENABLED(CLASSIC_JERK)
  #define DEFAULT_XJERK 400
  #define DEFAULT_YJERK 400
  #define DEFAULT_ZJERK  2.0

  //#define LIMITED_JERK_EDITING        // Limit edit via M205 or LCD to DEFAULT_JERK * 2
  #if ENABLED(LIMITED_JERK_EDITING)
    #define MAX_JERK_EDIT_VALUES { 20, 20, 0.6, 10 } // ...or, set your own edit limits
  #endif
#endif

#define DEFAULT_EJERK    200.0  // May be used by Linear Advance

@mcdanlj I tried the solution presented at the post you shared but it didn't work. I will look at klipper to have a better idea of how it could help.

When you followed the "0.0" hack did you also see in the upstream issue the link to [github.com] ?

Active development in upstream marlin here including [github.com]

But note the concerns about performance of transcendentals in that issue; in klipper all that work happens on a more capable processor and it uses the CPU on the SKR only as a motion controller; a different architecture.