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 .

[rtyr]

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]

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]

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

[lunatic1972]

Both are in English

[lunatic1972]

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]

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

[foreachthing]

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]

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]

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]

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]

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 https://github.com/prusa3d/PrusaSlicer/issues/6996#issuecomment-925693313, 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]

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]

I agree and disagree

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

[mroek]

@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]

@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]

@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]

@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 https://github.com/prusa3d/PrusaSlicer/issues/6996#issuecomment-951798121, 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]

@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]

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]

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]

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]

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]

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]

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]

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]

@AndreasALu, @Akedan why don't you just write your own little post processing script? I don't think PS will revert these changes...

[mroek]

PS will not revert, but I still think the decision to change behaviour from previous versions was a bad one, and completely unnecessary.

I would recommend complaining to Craftbot to get them to fix their firmware, because even if I don't agree with the decision PS made, the Craftbots really should handle G-code both with and without leading zeroes.

Until it is fixed (if ever), a post-processing script is the way to go.

[AndreasALu]

@AndreasALu, @Akedan why don't you just write your own little post processing script? I don't think PS will revert these changes...

Because it makes more sense for several CB users to write post processing scripts than to solve the initial problem ;-)

[AndreasALu]

I would recommend complaining to Craftbot to get them to fix their firmware, because even if I don't agree with the decision PS made, the Craftbots really should handle G-code both with and without leading zeroes.

I checked every document available regarding number formats in RepRap code. I only found examples in the docs, where not a single one was without a leading zero. So CB's Interpretation of RepRap is much closer to the "standard" than PS'. It's only a few minutes work for a developer willing to solve it. So again, it would be a kind move for PS to solve the problem they introduced. Unless it was an active decision to get rid of leading zeroes to win the competition for the leanest g-code 😉

[Akedan]

PS will not revert, but I still think the decision to change behaviour from previous versions was a bad one, and completely unnecessary.

I would recommend complaining to Craftbot to get them to fix their firmware, because even if I don't agree with the decision PS made, the Craftbots really should handle G-code both with and without leading zeroes.

Until it is fixed (if ever), a post-processing script is the way to go.

I'm just a stupid Swede who does not know how to write scripts and Craftbot says that they follow the RepRap standard so I will probably have to downgrade to 2.3 and stick to it in the future

[bubnikv]

The change was done as an optimization. Every time one does any change, there will be some people complaining. Thus avoiding a change puts a stop to any development.

Since the change was done a couple of months ago we have heard of two customers of CraftBot that were affected negatively by the change. We don't know how many CraftBot machines are affected, whether it is all of their models or just some of them, what firmware they are using, we were not contacted by CraftBot. CraftBot also produces their own slicer.

No other machine was affected by the change but some unknown to us CraftBot models as far as we are aware of.

ne 26. 12. 2021 v 21:30 odesílatel Akedan @.***> napsal:

PS will not revert, but I still think the decision to change behaviour from previous versions was a bad one, and completely unnecessary.

I would recommend complaining to Craftbot to get them to fix their firmware, because even if I don't agree with the decision PS made, the Craftbots really should handle G-code both with and without leading zeroes.

Until it is fixed (if ever), a post-processing script is the way to go.

I'm just a stupid Swede who does not know how to write scripts and Craftbot says that they follow the RepRap standard so I will probably have to downgrade to 2.3 and stick to it in the future

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/6996#issuecomment-1001238730, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSIYXSNBR54FZ4UIGH23US53OXANCNFSM5EROTT6Q . 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.

You are receiving this because you modified the open/close state.Message ID: @.***>

[AndreasALu]

Thank you for the clarification.

The affected printers are all the current CB models (FLOW series) and probably all older models as well. The reason you have not heard from more users is that it only started with PS 2.4 which is rather new. Getting other non-CB slicers to run with the CB printers is not easy, and only currently a CB user published how to use PS with the CB printers. So mostly PS < 2.4 is used, without issues. CB is very closed when it comes to using other slicers, and it's a pity that when someone finally got PS to run, it's not working anymore. Personally I use PS only for my 5 Prusa printers and Cura for the rest of the farm, otherwise I would publish how to write a script to fix the issue. Of course it would be better to fix the root cause, and it only needs to be fixed for RepRap syntax.

[foreachthing]

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 :grin: )

"""
    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]

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]

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]

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]

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]

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

[bubnikv]

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

[AndreasALu]

@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]

@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]

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]

@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]

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]

@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]

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

https://github.com/prusa3d/PrusaSlicer/issues/7505#issuecomment-996511504

[foreachthing]

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

[AndreasALu]

@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]

@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]

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.