An option to keep G0 and G1 movement speeds separate

Nikolay-Po commented 1 year ago

Is your feature request related to a problem?

To let firmware define fast traveling speed without editing printing profile in a slicer, I tried to use G0 separate feedrate setting. For this purpose I enabled variable G0 feedrate in Marlin 2.1.x configuration and this lead to a problem: When variable G0 feedrate enabled, Marlin separates G0 feedrate from G1 feedrate and setting G1 feedrate become independent on G0 feedrate parameter. But Cura uses G0 F parameter for subsequent G1 movements, assuming G0 feedrate will unconditionally change G1 feedrate. As was described in #13826, incorrect speed for extruding moves is applied for second and next layers.

The problem is not practical yet, but may help Cura to get closer to mature CNC industry. I'm using the printer not only for FDM prints but for putting a masks for printed circuit boards and other tasks, even for 3D-measurements. So I need more freedom, best support of G-code. And G0 feedrate is one of the case.

Describe the solution you'd like

Most important. A check box in machine settings (printer settings): "Separate G1/G0 feedrates". Proposed description: "Set if printer treats G1 feedrate setting separately from G0 feedrate (CNC-style G-code). Also set if default G0 feedrate enabled in Marlin". Unchecked - current behavior, G0 assumed to be an alias of G1 with zero extrusion. Checked - G1 feedrate assumed completely separated from G0 feedrate. When G1 feedrate need to be changed, G1 command with "F" parameter issued. G0 feedrate change doesn't change G1 feedrate.
A check box in speed settings: "Use printer own speed for travels". Proposed description: "Set if printer uses own, machine-specific speed for travels (CNC-sytle G-code). None feedrate setting will be used with G0 commands". Unchecked - current behavior, user-supplied travel speed values are passed in "F" parameter of G0 command. Checked - travel speed setting in speed folder become inactive (or even disappearing) and G0 command is used for travels without of "F" parameter.

Describe alternatives you've considered

An alternative is to left Cura as is. I can re-compile Mariln Firmware disabling G0 variable speed and will keep using Cura as before.

Affected users and/or printers

Affected printers under Marlin Firmware 2.x.x control (or newer) if G0_FEEDRATE defined and, optionally, VARIABLE_G0_FEEDRATE enabled. The users of CNC machines who wants to slice in Cura for FDM prints, say, portal printer for large object printing, may be affected too.

Additional information & file uploads

Here separate G0/G1 feedrate interpretation is activated for Marlin Firmware. G0_FEEDRATE definition makes G1 feedrate independent on G0 one.

// Enable and set a (default) feedrate for all G0 moves
#define G0_FEEDRATE 3600 // (mm/min)
#ifdef G0_FEEDRATE
  #define VARIABLE_G0_FEEDRATE // The G0 feedrate is set by F in G0 motion mode
#endif

I tried to print more common model with an infill. If G0/G1 feedrates are separate in machine and some speeds set equivalent (for example, wall speed is equal to travel speed) and some different (infill speed), then printing speeds may be incorrect, depending on which command was sent previously - G0 or G1. For example, a thick infill line was printed at speed of 94mm/s. Then travel motion performed at 188mm/s. Then wall printing motion at 188mm/s planned. in this case, wall will be printed at 94mm/s incorrectly because slicer assumes that printing speed is already set to 188mm/s by G0 command which is not the case for printer with separate G0/G1 speed.

A citations from Marlin Firmware website:

By convention, most G-code generators use G0 for non-extrusion movements (those without the E axis) and G1 for moves that include extrusion. This is meant to allow a kinematic system to, optionally, do a more rapid uninterpolated movement requiring much less calculation.

Yes, exactly this approach I want to use to not bothering by travel speeds, assuming they are kept printer firmware and stored in printer's EEPROM.

For Cartesians and Deltas the G0 (rapid linear movement) command is (and must be) a direct alias for G1 (rapid movement).

In my opinion, the aliasing of G1 for G0 command was extremely useful for tiny 8-bit chips with a lack of ROM and RAM. Today with 32-bit chips, some bytes of RAM and hundred bytes of ROM are not a problem. And printer may become closer to true CNC machine and provide more convenience eliminating travel speed control from a slicer.

Marlin 2.0 introduces an option to maintain a separate default feedrate for G0. Note: Slicers tend to override firmware feedrates!

The second proposition is specially to not override G0 feedrate.

GregValiant commented 1 year ago

Maybe something similar to "Always Write Active Tool" but "Always Write Speed"?

Nikolay-Po commented 1 year ago

@GregValiant, no, "Always Write Speed" can be interpreted as "Write speed again even if it was just written, even the same motion type". May be: "Set G0/G1 speeds separate"? Or, if you need some mist: "Obey linear motion type"?

Praveen-Rai commented 1 year ago

Hello everyone,

I observed that the G1 Feed-Rate is way less than the Print Speed ( & Wall Speed ) specified. STL, 3mf & generated g-code files . The model is a simple cuboid, sliced as a single walled object.

The actual Print Speed ( set to 100 mm/s ) is only observed during the first layer ( line : 299 - 303 )

G1 F6000 X167.15 Y122.15 E84.45356
G1 X167.15 Y117.5 E84.85954
G1 X167.15 Y112.85 E85.26552
G1 X67.85 Y112.85 E93.93519
G1 X67.85 Y122.15 E94.74715

For all other layers the feed-rate is set to 1303.2 mm/min ( ~22 mm/s ) ( for e.g. Line : 321 - 325 )

G1 F1303.2 X167.15 Y122.15 E122.38009
G1 X167.15 Y117.5 E122.78607
G1 X167.15 Y112.85 E123.19205
G1 X67.85 Y112.85 E131.86172
G1 X67.85 Y122.15 E132.67368

I couldn't find any other setting that could be slowing down / limiting the wall printing speed.

Please let me know if this should be tracked as a different issue. I felt it would be good to have these observation too in this discussion. Apologies if it causes distraction.

GregValiant commented 1 year ago

@Praveen-Rai this should have been a different issue but don't bother.

Your Project file did not generate that gcode file. The reason I know that is the reason for your slow down. There is a lot more extruding going on on Layer 1 than on the subsequent layers. You are bouncing off the "Minimum Layer Time" (Cooling section in Cura). With three skirt loops around the model it took long enough to print that the initial layer time was over the default 10 seconds. Printing only the walls on the subsequent layers the layer time dropped below 10 seconds so Cura slowed down the print head just as you requested in your settings. Your Project File has only a single loop and so the Initial Layer prints faster and the project file hit the minimum layer time even on the initial layer.

If you are trying to calibrate "Flow" using a single wall cube all you will accomplish is to calibrate your printer to make great single wall cubes. All other prints will be under-extruded. Calibrate your E-steps, measure the filament diameter and enter that measurement into Cura, and you are all done.

Ultimaker / Cura