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

lunatic1972 · 2021-09-22T14:25:57Z

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
.

rtyr · 2021-09-22T18:16:25Z

G1 Z.21 F6000 (Would fail)

I am not sure I understand. We are not emitting such commands as far as I know.

g-code generated from your project file:
3_INCoreEjectPlate_REV2.zip

lunatic1972 · 2021-09-22T18:26:43Z

I've attached my current print settings along just in case but pretty sure it has nothing to do with the issue.
I guess I should have specified more so, the gcode that's sliced has that. If you slice the above file, the following lines all have it:
The lines below would cause the craftbot flow to fail without prepending the 0. prior to the number. Instead of .21 it needs 0.21 as an example
Line 58: G1 Z.21 F8700
Line 3048: G1 Z.41 F8700
Line 4492: G1 Z.61 F8700
Line 5910: G1 Z.81 F8700

Line 3003: G1 E.52542 F1800
Line 4490: G1 E.57211 F1800
Line 19315: G1 E.99544 F1800
Line 19359: G1 E.20462 F1800
Line 22622: G1 E.99544 F1800
Line 25845: G1 E.99544 F1800
Line 25889: G1 E.20462 F1800
Line 27359: G1 E.49647 F1800
Line 29110: G1 E.99544 F1800
Line 29154: G1 E.20462 F1800
Line 32290: G1 E.99544 F1800
Line 38827: G1 E.99544 F1800
Line 40422: G1 E.49614 F1800
Line 60024: G1 E.49614 F1800
Line 63729: G1 E.49668 F1800
Line 67285: G1 E.49665 F1800
Line 69142: G1 E.4989 F1800
Line 71131: G1 E.21106 F1800
Line 71248: G1 E.95004 F1800
Line 71616: G1 E.49629 F1800
Line 71691: G1 E.49925 F1800
Line 72632: G1 E.40593 F1800
Line 73502: G1 E.45529 F1800
Line 74211: G1 E.49925 F1800
Line 75153: G1 E.40593 F1800
Line 76128: G1 E.72136 F1800
Line 76686: G1 E.49658 F1800
Line 76769: G1 E.49938 F1800
Line 78740: G1 E.20462 F1800
Line 78755: G1 E.00326 F1800
Line 79437: G1 E.49904 F1800
Line 81581: G1 E.49654 F1800
Line 81698: G1 E.20849 F1800
Line 81815: G1 E.95005 F1800
Line 82083: G1 E.49901 F1800
Line 83019: G1 E.40593 F1800
Line 84749: G1 E.49868 F1800
Line 86883: G1 E.49597 F1800
Line 87028: G1 E.22363 F1800
Line 87145: G1 E.95005 F1800
Line 87412: G1 E.49871 F1800
Line 89372: G1 E.20462 F1800
Line 89562: G1 E.91078 F1800

Currentconfig.zip
e

rtyr · 2021-09-22T18:32:31Z

Hmm. What language do you have set in the PrusaSlicer? Also in what language is your OS?

lunatic1972 · 2021-09-22T19:17:29Z

Both are in English

lunatic1972 · 2021-09-22T19:24:58Z

I just checked the Windows 64 bit released version of 2.3.3, and the problem did not exist there. So it was somewhere after that, that there was a change made. Hope this helps a little

lukasmatena · 2021-09-22T21:28:09Z

@lunatic1972 Thanks, reproduced. The fix is on the way.
Just to be clear, you have compiled current master yourself, right? 2.4.0-alpha1 did not suffer from this yet.

…l point

foreachthing · 2021-09-23T03:39:10Z

The title is a little vague however an example:
G1 Z.21 F6000 (Would fail)
G1 Z0.21 F6000 (Would work just fine)

Just fixed my regex yesterday, because of missing leading zeros. My postprocessor skipped through that part.
So, yeah! Same here! The UM2 started printing in thin air. Just the first layer, then it dropped to the second layer and printed normal.

bubnikv · 2021-09-23T06:54:44Z

Wait a minute:

https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374
page 17, 3.3.2.1 Number.

Based on the G-code norm, the leading or trailing zeros do not need to be emitted.

Which products could not consume such a valid G-code?

foreachthing · 2021-09-23T07:41:31Z

Ok! I found the issue! The issue was with my post processing, because I expected "0.2" (as in first layer height) and then it failed because it has never found "0.2" -> "Z.2" is not equal to "Z0.2".
After fixing my regex, it works.

lunatic1972 · 2021-09-23T10:34:57Z

Wait a minute:

https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374
page 17, 3.3.2.1 Number.

Based on the G-code norm, the leading or trailing zeros do not need to be emitted.

Which products could not consume such a valid G-code?

I would agree that it really is a strange thing to fail on since numerically they are identical however the Predator processor for Craftbot apparently doesn't see it that way since it gets processed as text obviously. Hopefully this fix will help others and I'm definitely grateful the PrusaSlicer team is so very responsive. Keep up the great work!

bubnikv · 2021-09-23T11:23:10Z

Frankly if the only software that cannot process such a G-code is some "Predator processor for Craftbot", then we would ask the "Predator processor for Craftbot" to be fixed. čt 23. 9. 2021 v 12:35 odesílatel lunatic1972 ***@***.***> napsal:

…

Wait a minute: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374 page 17, 3.3.2.1 Number. Based on the G-code norm, the leading or trailing zeros do not need to be emitted. Which products could not consume such a valid G-code? I would agree that it really is a strange thing to fail on since numerically they are identical however the Predator processor for Craftbot apparently doesn't see it that way since it gets processed as text obviously. Hopefully this fix will help others and I'm definitely grateful the PrusaSlicer team is so very responsive. Keep up the great work! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSI6FFTZNZE5B7W5O6J3UDL7FXANCNFSM5EROTT6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

lunatic1972 · 2021-09-24T10:04:36Z

I agree and disagree but here's why. In the version that was released on GitHub for 2.3.3 the g-code generated by PrusaSlicer and prior did have the 0. prepended to numbers whereas somewhere after that it changed so I personally think it should stay consistent. G-code generation should be consistent throughout. But I will also reach out to CraftBot on the issue since it really is out of spec per the document

bubnikv · 2021-09-24T10:59:55Z

I agree and disagree

I have a mixed feeling about the topic as well. Let's wait for wider response.

mroek · 2021-10-26T08:50:16Z

@lukasmatena In 2.40-beta1, I am observing extrusion lengths in the emitted G-code without a leading zero. Did your fix not make it to that version?

bubnikv · 2021-10-26T10:11:17Z

@mroek we did not change that. Why are missing leading zeros a problem for you? The G-code is perfectly valid according to the G-code specification.

mroek · 2021-10-26T10:25:10Z

@mroek we did not change that. Why are missing leading zeros a problem for you? The G-code is perfectly valid according to the G-code specification.

@bubnikv When I saw this issue, I thought it could be an issue for me, since I am using a Craftbot. However, my Craftbot is not the Flow model, and it appears that my model is not affected by this (so not really an issue for me).

However, even if the specification allows for dropping the leading zero, previous Prusaslicer versions did include that zero, so removing it could cause issues for some printers (like the Craftbot Flow, apparently), and for no good reason. I think it makes sense to keep it for consistency, even if I agree that printers definitely should handle distances that lacks the leading zero.

So in short, I think Prusaslicer should include the zero (and it also makes the G-code more readable for humans), and I think that Craftbot should fix their firmware as well.

bubnikv · 2021-10-26T14:40:01Z

@mroek The alphas / betas are there to collect feedback. If Craftbot Flow is the only reason to roll back, I would not do it. út 26. 10. 2021 v 12:25 odesílatel mroek ***@***.***> napsal:

…

@mroek <https://github.com/mroek> we did not change that. Why are missing leading zeros a problem for you? The G-code is perfectly valid according to the G-code specification. @bubnikv <https://github.com/bubnikv> When I saw this issue, I thought it could be an issue for me, since I am using a Craftbot. However, my Craftbot is not the Flow model, and it appears that my model is not affected by this (so not really an issue for me). However, even if the specification allows for dropping the leading zero, previous Prusaslicer versions did include that zero, so removing it could cause issues for some printers (like the Craftbot Flow, apparently), and for no good reason. I think it makes sense to keep it for consistency, even if I agree that printers definitely should handle distances that lacks the leading zero. So in short, I think Prusaslicer should include the zero (and it also makes the G-code more readable for humans), and I think that Craftbot should fix their firmware as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSI3BJUNHU47XL5QFDL3UI2F2DANCNFSM5EROTT6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

mroek · 2021-10-26T14:45:47Z

@bubnikv But why was it changed in the first place? It doesn't harm anything (other than a slightly large file size) to have that zero in front of the decimal point, does it? And arguably, it looks better when inspecting the file manually.

Other than that, as I've already said, I think Craftbot should also fix their parser.

foreachthing · 2021-10-26T15:01:40Z

Just make a short (Python) post processing script to change all F-numbers. Then PS can focus on something else and you get valid gcode for your machine.

mroek · 2021-10-26T15:17:51Z

Just make a short (Python) post processing script to change all F-numbers. Then PS can focus on something else and you get valid gcode for your machine.

That's besides the point, really. And as I said, my machine does handle it correctly, so I'm not advocating for myself here. I'm just wondering why it was changed in the first place, because whenever possible I think it makes sense to try to stay consistent. Previous versions of PS did print those zeros (and I think most other slicers do too). Also the change to fix it has already been done, and it's just a few lines of code.

foreachthing · 2021-10-26T15:54:14Z

That's besides the point, really.... Previous versions of PS did print those zeros (and I think most other slicers do too). Also the change to fix it has already been done, and it's just a few lines of code.

Sure, I agree.
PS has changed more things that worked and suddenly the user has to fix it (or work around it). I don't feel PS wants to change that back... like previous changes they did.

Since I run every file through post processing, it was easy to undo their "fix".

lunatic1972 · 2021-10-30T12:44:19Z

I just want to comment that the programmers have really done a great job on this software so far however using a script to change the gcode to accommodate running is really not the best solution in my opinion. Could I? Sure I could but when it ran fine in 2.3 series and something changed in 2.4 for gcode readability I believe that would be a regress in the software that could easily be remedied since it's merely a formatting issue. It's been a few years out of programming for me otherwise I would gladly help however I don't know the code base to look for it

bubnikv · 2021-12-08T14:15:48Z

The only software that cannot process such a G-code seems to be some "Predator processor for Craftbot", we are asking the "Predator processor for Craftbot" to be fixed.

Closing

AndreasALu · 2021-12-26T03:43:36Z

So instead of changing a few lines of code in a software that was in Alpha and Beta back to how it was before in older versions (and we are not talking about changing a new function, but changing presumably only a format string), the competitor Craftbot has to change the firmware of it's printers (that worked with older versions of PS). Not sure if JP would say that this is a great customer oriented solution.

Akedan · 2021-12-26T09:14:38Z

I use a Craftbot Flow and have used PS since v2.2 on my work and I was impressed with the features and speed that the developers come with upgrades. (I have used Simplify 3d before on my home printer) but I got a little frustrated after 3 hours of troubleshooting when I discovered that there was a zero missing in the g-code when I upgraded to 2.4. so please fix this little problem🙏

foreachthing · 2021-12-30T22:10:07Z

So, just in case anyone still needs to "fix" this, I could not let it be and wrote this little post processing script:

(NOTE: this script will reformat ALL numbers found in .gcode! No exceptions. Error catching is held to a minimum 😁 )

"""
    Reformat ALL the numbers.
    Example: replace .05 with 0.05
"""

import sys
import re
import decimal
from decimal import Decimal

SOURCEFILE = sys.argv[1]
REGEX = r"-?\d*\.?\d+"

def main(sourcefile):
    """
    Main.

    Args:
        sourcefile ([string]): [the source gcode file]
    """
    # Read the ENTIRE GCode file into memory
    lines = ""
    with open(sourcefile, "r", encoding='UTF-8') as readfile:
        lines = readfile.readlines()

    # Replace the gcode file.
    # Replace ALL(!!!) the numbers with format_number().
    with open(sourcefile, "w", newline='\n', encoding='UTF-8') as writefile:
        # loop over gcode file in memory
        for i, strline in enumerate(lines):
            # Find ALL numbers
            matches = re.finditer(REGEX, strline, re.MULTILINE)
            for matchNum, match in enumerate(matches, start=1):
                # Replace each number with the correct formatted number
                strline = strline.replace(match.group(), format_number( match.group()))
            # Write line back to file
            writefile.write(strline)


def format_number(num):
    """
        https://stackoverflow.com/a/5808014/827526

    Args:
        sourcefile ([string]): [number to be formatted correctly]
    """
    try:
        dec = Decimal(num)
    except decimal.DecimalException as ex:
        print(str(ex))
        # return f'Bad number. Not a decimal: {num}'
        return "nan"
    tup = dec.as_tuple()
    delta = len(tup.digits) + tup.exponent
    digits = ''.join(str(d) for d in tup.digits)
    if delta <= 0:
        zeros = abs(tup.exponent) - len(tup.digits)
        val = '0.' + ('0'*zeros) + digits
    else:
        val = digits[:delta] + ('0'*tup.exponent) + '.' + digits[delta:]
    val = val.rstrip('0')
    if val[-1] == '.':
        val = val[:-1]
    if tup.sign:
        return '-' + val
    return val


main(SOURCEFILE)

Copy the code above, save it as .py (i.e. numberformater.py) and add that script to the post processing section of PrusaSlicer.
Maybe so:

"C:\Users\USERNAME\AppData\Local\Programs\Python\Python39\python.exe" "C:\dev\numberformater.py";

Script also found here, in case of issues:
https://github.com/foreachthing/prusaslicer-numberformatter

Akedan · 2021-12-30T22:35:15Z

Super great👍I will try this script next week when i get back to work, thank you so much for your efforts/Happy new year

lunatic1972 · 2021-12-31T21:01:30Z

Just tried it in 2.4RC and I used notepad++ to check for padded numbers and it looked good. Next week I'll check it on craftbot. Thanks for the awesome script! Too bad there wasn't a programmatic way in the program ;)

iff7378 · 2022-01-04T21:52:45Z

Can confirm this is an issue after upgrading to PS2.4.0 on my Craftbot FLOW. I'll email them and see if they would release an update to their firmware. However, their support has generally be less than stellar.

basrijn · 2022-01-05T19:59:28Z

Another Craftbot user here. Now that that 2.4 is official, I made the switch. As per Andreas his note, it would be great to stick to the commonly used RepRap GCode (ie, with the leading zero).

I've been using Prusa on my Craftbot with great success and would like to stay with it

bubnikv · 2022-01-06T07:39:00Z

@basrijn What is the response of our Hungarian friends at Craftbot?

bubnikv · 2022-01-06T07:40:18Z

@basrijn Frankly why should we support Craftbot's customers? Shouldn't Craftbot support their customers? Shouldn't you bug them?

AndreasALu · 2022-01-06T07:50:16Z

@basrijn Frankly why should we support Craftbot's customers? Shouldn't Craftbot support their customers? Shouldn't you bug them?

Because it would show that you are above fighting petty wars with your competition where the customers are the ones loosing. If I were to decide between different brands of printers, I would lean towards the company with better customer service, and clearly Prusa can stand out here. There are multiple users not satisfied with Craftbot, and with the XL in the pipeline, a lot of them will look forward to it. It's not a good signal if you start a blame game because of a fix that would take minutes to implement, and it would push you down to the CB level.

bubnikv · 2022-01-06T07:55:49Z

@AndreasALu

Because it would show that you are above fighting petty wars with your competition where the customers are the ones loosing.

You are very wrong. All 3D printing firmware in the known universe with the exception of CraftBot seems to follow the rules of formatting CNC G-codes.

If we reverted our changes, G-codes for all 3D printers in the known universe would grow slightly because a single 3D printer manufacturer in the known universe does not follow the rules and this particular 3D printer manufacturer is keeping his ecosystem closed anyways.

bubnikv · 2022-01-06T07:57:37Z

Another reliable definition of G-code language:
Siemens SINUMERIK SINUMERIK 840D sl / 828D Fundamentals, Page 405
https://cache.industry.siemens.com/dl/files/554/74475554/att_56792/v1/PGsl_0313_en_en-US.pdf

bubnikv · 2022-01-06T08:02:33Z

@AndreasALu

And frankly you paid them for your printer. You paid us nothing. If it is such a tiny change you require us to do, shouldn't it be a tiny change for your 3D printer vendor as well? And they will become conformant to the standard. So all in all, it is the firmware that shall change to make the world better.

mroek · 2022-01-06T08:21:48Z

As an aside, how many other slicers for 3D-printers emit G-code without leading zeroes? I'm guessing that the normal thing is to include them. File size is of course smaller without, but does it really matter with a few percent (at most)?

Older Craftbots works fine also with the current version of Prusaslicer, it is just the newer Flow series that chokes on it. And they should fix it, no doubt. However, adding back the zeroes in PS (making it a selectable option) is also a simple thing to do, and would show support for the users of PS that needs this. It isn't about supporting Craftbot, per se.

AndreasALu · 2022-01-06T08:48:53Z

@AndreasALu

And frankly you paid them for your printer. You paid us nothing.

That's where you are wrong. Well, I did pay for your slicer through buying 5 of your printers.

bubnikv · 2022-01-06T09:06:50Z

@AndreasALu

That's where you are wrong. Well, I did pay for your slicer through buying 5 of your printers.

I am sorry, I did not know. Thank you for supporting the development of PrusaSlicer.

We are considering to implement a generic text substitution tool for the planned PrusaSlicer 3.4.1 patch release, thus the following substitution will then be available at the print profiles.

#7505 (comment)

foreachthing · 2022-01-06T09:16:56Z

Why not make it an option (zero or not) and everybody is happy again?!

AndreasALu · 2022-01-06T09:21:57Z

@AndreasALu

That's where you are wrong. Well, I did pay for your slicer through buying 5 of your printers.

I am sorry, I did not know. Thank you for supporting the development of PrusaSlicer.

We are considering to implement a generic text substitution tool for the planned PrusaSlicer 3.4.1 patch release, thus the following substitution will then be available at the print profiles.

#7505 (comment)

Thank you. I hope it's 2.4.1 and not 3.4.1 😁

bubnikv · 2022-01-06T10:30:30Z

@foreachthing

Why not make it an option (zero or not) and everybody is happy again?!

Perfectionist in me would suffer. Why making the product worse just to patch an error in Craftbot firmware?

iff7378 · 2022-01-06T11:06:19Z

I agree that Craftbot should be the ones to perform the fix in this case. It comes with a 5 year warranty, they're on the hook for a fairly pricey printer to make sure it works. In the meantime, we have a post script that provides a temporary fix so I don't see the reason to pressure PS into fixing something that isn't technically incorrect. We need to encourage Craftbot users to contact their support and ask for a firmware update.

iff7378 · 2022-01-06T14:09:30Z

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 · 2022-01-27T16:27:12Z

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 · 2022-01-27T16:47:39Z

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 · 2022-02-04T22:11:58Z

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 · 2022-02-16T12:27:31Z

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 · 2022-03-07T19:43:48Z

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 · 2023-03-11T11:42:23Z

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).

rbeverly · 2024-12-15T23:26:33Z

I found that this now closed issue also affects some Qidi printers, at least the X-one 2 (which I still have from 2017).

Slicing in Fusion or Simplify3D results in working gcode for the machine, but Prusaslicer 2.8.0 (my current version on Solus) omits some leading zeros, and that makes the code "not work" on this printer (prints in mid-air, fails to layer switch, fails to extrude, etc, wherever it outputs something like G1 Z.24).

I suspect there are other older machines out there that won't be getting firmware updates, that will have this issue. However, many normal users will not be able to figure out what the problem with the gcode is; it's quite subtle when you're looking at files side by side. If I hadn't spent the better part of a week experimenting, I would have just assumed the printer "doesn't work" with PrusaSlicer.

For now I'll use gcode substitutions or a post processing script, since I use PrusaSlicer for the Prusa printers, and don't want to switch slicers. Maybe the late comment will be of use to someone experiencing printing issues on older or less known printers.

lukasmatena added a commit that referenced this issue Sep 22, 2021

Fix of #6996: numbers in gcode commands shall not start with a decima…

16f1bd5

…l point

sej7278 mentioned this issue Sep 25, 2021

G92 (and post-processing) breaks in PrusaSlicer 2.4 alpha2 DrLex0/FFCP-GCodeSnippets#15

Closed

bubnikv added the awaiting response label Oct 23, 2021

bubnikv closed this as completed Dec 8, 2021

neophyl mentioned this issue Dec 16, 2021

G1 E GCODE is getting generated without a whole number #7505

Closed

bubnikv mentioned this issue Mar 25, 2022

Gcode extractor preceeding 0 not in gcode anymore New Slicer 2.4.0 #7554

Closed

rtyr mentioned this issue Mar 10, 2023

Gcode for Z is missing leading zero, and possibly extraneous usage #10013

Closed

2 tasks

neophyl mentioned this issue Nov 8, 2023

2.7-alpha1 skips leading zero on G2 J/I parameters for legacy marlin machines (Snapmaker A350) #11620

Closed

2 tasks

moberli mentioned this issue Nov 17, 2023

Slic3r leading zero missing in Z movement MosaicManufacturing/canvas-issues#274

Closed

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

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

Comments

lunatic1972 commented Sep 22, 2021

rtyr commented Sep 22, 2021

lunatic1972 commented Sep 22, 2021 • edited Loading

rtyr commented Sep 22, 2021

lunatic1972 commented Sep 22, 2021

lunatic1972 commented Sep 22, 2021

lukasmatena commented Sep 22, 2021 • edited Loading

foreachthing commented Sep 23, 2021 • edited Loading

bubnikv commented Sep 23, 2021

foreachthing commented Sep 23, 2021

lunatic1972 commented Sep 23, 2021

bubnikv commented Sep 23, 2021 via email

lunatic1972 commented Sep 24, 2021

bubnikv commented Sep 24, 2021

mroek commented Oct 26, 2021

bubnikv commented Oct 26, 2021

mroek commented Oct 26, 2021

bubnikv commented Oct 26, 2021 via email

mroek commented Oct 26, 2021

foreachthing commented Oct 26, 2021

mroek commented Oct 26, 2021

foreachthing commented Oct 26, 2021 • edited Loading

lunatic1972 commented Oct 30, 2021

bubnikv commented Dec 8, 2021

AndreasALu commented Dec 26, 2021

Akedan commented Dec 26, 2021

foreachthing commented Dec 30, 2021 • edited Loading

Akedan commented Dec 30, 2021

lunatic1972 commented Dec 31, 2021

iff7378 commented Jan 4, 2022

basrijn commented Jan 5, 2022

bubnikv commented Jan 6, 2022

bubnikv commented Jan 6, 2022

AndreasALu commented Jan 6, 2022

bubnikv commented Jan 6, 2022

bubnikv commented Jan 6, 2022

bubnikv commented Jan 6, 2022

mroek commented Jan 6, 2022

AndreasALu commented Jan 6, 2022

bubnikv commented Jan 6, 2022

foreachthing commented Jan 6, 2022

AndreasALu commented Jan 6, 2022

bubnikv commented Jan 6, 2022

iff7378 commented Jan 6, 2022

iff7378 commented Jan 6, 2022

bubnikv commented Jan 27, 2022

mroek commented Jan 27, 2022

KimmoHop commented Feb 4, 2022

svengl commented Feb 16, 2022

tastymagma2 commented Mar 7, 2022

Tupson444 commented Mar 11, 2023 • edited Loading

rbeverly commented Dec 15, 2024

lunatic1972 commented Sep 22, 2021 •

edited

Loading

lukasmatena commented Sep 22, 2021 •

edited

Loading

foreachthing commented Sep 23, 2021 •

edited

Loading

foreachthing commented Oct 26, 2021 •

edited

Loading

foreachthing commented Dec 30, 2021 •

edited

Loading

Tupson444 commented Mar 11, 2023 •

edited

Loading