Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export as gcode actually exports bgcode #11498

Closed
2 tasks
ex-nerd opened this issue Oct 21, 2023 · 8 comments
Closed
2 tasks

Export as gcode actually exports bgcode #11498

ex-nerd opened this issue Oct 21, 2023 · 8 comments

Comments

@ex-nerd
Copy link

ex-nerd commented Oct 21, 2023

Description of the bug

PrusaSlicer 2.7.0-alpha1: When I click the Export G-code button, and then explicitly select *.gcode from the menu as the file type, the file exported file is still in the new bgcode format. The opposite is true if I change the printer from my Prusa XL to my older DuetWifi printer (it always exports gcode even if I explicitly request bgcode).

Project file & How to reproduce

This happens with any project file I've tested.

  • Set up and slice something you want to print
  • Click the Export G-code button
  • If using a Prusa XL printer profile
    • Select *.gcode as the export file format, and save the file
    • Note that the contents of the file are the new binary gcode format, despite *.gcode file suffix
  • If using a non-Prusa printer profile
    • Select *.bgcode as the export file format, and save the file
    • Note that the contents of the file are still in regular text gcode format, despite *.bgcode file suffix

Checklist of files included above

  • Project file
  • Screenshot

Version of PrusaSlicer

2.7.0-alpha1

Operating system

MacOS 14.0, ARM (M2 Pro)

Printer model

Prusa XL (latest beta firmware)

@lukasmatena
Copy link
Collaborator

The format of the file is set according to the checkbox in Print Settings->Output options->Export as binary G-code. We are currently discussing options to make it more user-friendly.

@ex-nerd
Copy link
Author

ex-nerd commented Oct 23, 2023

The format of the file is set according to the checkbox in …

Thanks for the info. This is definitely confusing for Mac users, since the file-save dialog has been specifically used to set the "save as" file format since as far as I can remember (system 6 over 30 years ago). I would expect that the settings only affect the default value, but that by selecting the file format of *.gcode (honestly, even if I just set the filename to *.gcode) that the export would respect my request to override that default for this one specific save action.

@rcmaniac25
Copy link

If you took a page from image and document editors, the format chosen for save should be the deciding element. So if gcode is selected, save in ASCII. If bgcode is selected, save in binary. Perhaps the printer has a setting if it supports binary gcode and if it does, the bgcode option is available. But if it isn't, then bgcode isn't available.

@lukasmatena
Copy link
Collaborator

Saving ASCII gcode as bgcode or vice versa is reported as an error in 2.7.0-beta1.
It is not technically easy to use the extension selected in the dialog, because the G-code export is already finished (or in progress) at that point. Closing.

@ex-nerd
Copy link
Author

ex-nerd commented Nov 11, 2023

Saving ASCII gcode as bgcode or vice versa is reported as an error in 2.7.0-beta1. It is not technically easy to use the extension selected in the dialog, because the G-code export is already finished (or in progress) at that point. Closing.

If you don't do things the correct way and put the save-as dialog up before generating the export, it would be nice if the dialog box didn't give the user the illusion of choice at all, and hard-coded the appropriate extension. However, I suppose throwing an error if they specify an incompatible type/extension (hopefully explaining where to go to make the change) is better than the old behavior.

@rcmaniac25
Copy link

I have to agree with @ex-nerd . An error message works... but given the illusion of choice is not really useful. I have not looked into how PrusaSlicer is doing it, but I know from libbgcode, you still need to pass in an ASCII gcode to the Binarizer so it can be converted to bgcode. This means there is still going to be an ASCII version.

So unless the concern is disk space being taken up by tmp files and/or some extra processing power when Generating Gcode, it is entirely possible to write both an ascii tmp file and a bgcode tmp file at the same time, with just:

file.write(asciiGcode);
if (printerConfig.supportBgcode) {
    binaryozer.append_gcode(asciiGcode);
}

and then when the file save dialog returns, to check the save filetype and copy the appropriate one.

@jonaskello
Copy link

What threw me off a bit was that the link in the error message navigated to the advanced tab (probably becuase I was previously at that tab) and there is no such setting there.

image

image

Took a while to realise that the actual setting is under the same place but the expert tab.

@attikov
Copy link

attikov commented Feb 21, 2024

This GUI is just very very bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants