Gcode fails on Craftbot flow without prepending a 0. prior to moves or extrudes

[lunatic1972]

Version: 2.4.0-alpha1 Windows 10 The title is a little vague however an example: G1 Z.21 F6000 (Would fail) G1 Z0.21 F6000 (Would work just fine) This also includes X, Y, Z and E moves where the number is less than 1. Is there a way to prepend the 0. to numbers smaller than 1 rather than using an editor and replacing all of them. It would be greatly appreciated I have also tried using different "g-code flavors' but the problem persists.

I've attached the project file however in this instance I don't believe it's necessary but for the sake of completeness

3_INCoreEjectPlate_REV2.zip .

[iff7378]

As expected: "Thanks for contacting the Craftbot support team. My name is Moncef and I will be more than happy to assist you in resolving this issue. Please use our Craftware slicer, the GCODE will contain 0 and the firmware will not run into errors."

Too bad their Craftware slicer is junk compared to PS. I'll push em a little harder.

[bubnikv]

The missing zeros will be added in PrusaSlicer 2.4.1-beta1 using the following regular expression

"( [XYZEF]-?).([0-9]+)"

and replace pattern

"\10.\2"

and checking "Regular expression" checkbox, something like this:

The final form will also contain a "comment" field for each find / replace pair.

[mroek]

That is excellent, @bubnikv ! Although I am not affected (my Craftbot is older, and does handle the missing zeroes), this is a completely acceptable solution for those that need it. It can be stored in printer profile, and thereby can be set once and then forgotten.

[KimmoHop]

A bit off-topic, but it amazes me that instead of just adding that leading 0, a lot more time was spent in this discussion making argument that it is not mandatory or how much it costs in efficiency... In the end, slicer "fix" is more likely to be distributed to users than printer firmware fix (often 0% chance). If there was a PR for leading 0, had it been approved?

Post-processor without additional software is a good thing also e.g. for printers that do not support M73.

[svengl]

This is great. A small addendum to the regex above I had to escape the "."

( [XYZEF]-?)\.([0-9]+)

Note the \. I am sure @bubnikv also did it, but the github markdown swallowed it. Thanks a lot.

[tastymagma2]

This also affects the Qidi Tech X-One (I believe they use a modified Sailfish version as firmware).

To add to the discussion: I don't think it's reasonable to assume every hardware out in the wild will support every detail of a standard. It hardly seems worth to switch from a safe default that worked for everyone just to shave a few kb of a file that's tens of mbs big.

Competing slicers like Simplify3D and Cura also include the leading zeros. I very much doubt these are the only two machines that rely on how every slicer put out coordinates for years.

[Tupson444]

I don't have this problem, but if there is no good reason to change something (correct me if I'm missing something please) and it does cause problems somewhere (if more examples haven't been reported yet, it doesn't mean there are none), why change?

Yes, GCODE file size is reduced (a bit). Are there any other benefits? Is it worth the fact that the slicer indeed got less universal because of this?

Also, I would argue that leading zeroes would make the GCODE more easy to read by humans.

(Edit: g-code substitution does work, I just missed comment by svengl)

Why not just adding a switch in the slicer, instead of using post processing or Gcode substitutions (if not simply having the leading zero as the only option)?

Despite the fact that this slicer is developed for Prusa machines and that it isn't obliged to be compatible with anything else, attitude "it should be fixed in the firmware" is just wrong in this case (because it's an easy fix for the slicer, and it was arguably a useless change in the first place).