Export to octoprint failing

[grm]

Hello,

I am still waiting for my balbu X1C, but I want to familiarize with bambustudio, so i decided to use it with my ender 5 plus in the meanwhile. The printer is running octoprint (latest version) and i integrated the printer and octoprint flawlessly. However, when i try to send the gcode directly to the printer using this popup :

I got a 500 eror coming back from octoprint :

In the octoprint logs, i see errors related to file encoding wich does not seems to be utf-8 :

2024-01-19 19:47:09,210 - octoprint - ERROR - Exception on /api/files/local [POST]
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 2529, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 1825, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 1823, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 1799, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/server/util/flask.py", line 1613, in decorated_view
    return func(*args, **kwargs)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/vendor/flask_principal.py", line 196, in _decorated
    rv = f(*args, **kw)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/server/api/files.py", line 676, in uploadGcodeFile
    display=canonFilename,
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_PrintTimeGenius/__init__.py", line 580, in new_add_file
    return self._file_manager.original_add_file(destination, path, file_object, links, allow_overwrite, printer_profile, None, display)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/filemanager/__init__.py", line 733, in add_file
    display=display,
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/filemanager/storage.py", line 894, in add_file
    file_object.save(file_path)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/filemanager/util.py", line 102, in save
    shutil.copyfileobj(source, dest)
  File "/home/pi/oprint/lib/python3.7/shutil.py", line 79, in copyfileobj
    buf = fsrc.read(length)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/filemanager/util.py", line 214, in read
    processed_line = self.process_line(line)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_dashboard/gcode_processor.py", line 73, in process_line
    line = line.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 42: invalid continuation byte

This works fine from the appimage and from my other mac computer :)

Maybe it is related to #6 , but as i defined an UTF-8 locale, i am not sure either so i created a second ticket.

Thanks again for your help and great job at porting bambustudio to flathub which i prefer over appimage.

[hadess]

You need to debug the OctoPrint side to figure out what it was that tripped it. I'm not sure why it's trying to parse GCode as UTF-8, but I'm not a specialist of that format...

[grm]

With the same printer and Octoprint, it works using the appimage version. I am not sure it is on Octoprint's side :)

I'll try to have a look in the build part from the the flatpak !

Jérémie

[hadess]

With the same printer and Octoprint, it works using the appimage version. I am not sure it is on Octoprint's side :)

Just because the appimage version of BambuStudio works doesn't mean that the Flatpak version is to blame. Even if it is, we need to know what is wrong in its output so we can fix it.

[grm]

I totally agree ! But it seems to have differences in the way things are produced :)

After further investigations, i managed to get the gcode produced from the flatpak version and the on produced by the appimage version, using the same printer profiles and the same filament profile.

There is a small difference between the two of them.

Appimage version :

; HEADER_BLOCK_START
; BambuStudio 01.08.04.51
; model printing time: 1h 1m 22s; total estimated time: 1h 2m 1s
; total layer number: 30
; model label id: 259
; filament_density: 1.27,1.24
; filament_diameter: 1.75,1.75
; max_z_height: 6.00
; HEADER_BLOCK_END

and the flatpak version :

; HEADER_BLOCK_START
; BambuStudio 01.08.04.51
; estimated printing time (normal mode) = �z�"^F^?
; total layer number: 30
; model label id: 224
; filament_density: 1.27,1.24
; filament_diameter: 1.75,1.75
; max_z_height: 6.00
; HEADER_BLOCK_END

We can see the crappy characters in the estimated printing time that may cause issue. With this line, the file is detected as data and without these chars, it is detected as ASCII text, with very long lines (663) .

Also, these lines are not the same, and by looking at the source code in GCodeProcessor.cpp in Bambulab, at line 481, there is indeed an if :

                    if (mode == PrintEstimatedStatistics::ETimeMode::Normal || machine.enabled) {
                        char buf[128];
                        if (!s_IsBBLPrinter) {
                            // Klipper estimator
                            sprintf(buf, "; estimated printing time (normal mode) = %s\n",
                                get_time_dhms(machine.time).c_str());
                            ret += buf;
                        } else {
                            // BBS estimator
                            sprintf(buf, "; model printing time: %s; total estimated time: %s\n",
                                    get_time_dhms(machine.time - machine.prepare_time).c_str(),
                                    get_time_dhms(machine.time).c_str());
                            ret += buf;
                        }

It seems that for my printer, in the flatpak, it is using the klipper estimator (stated by the comment in the code) but in appimage it is using the BBS estimator. s_IsBBLPrinter seems to be evaluated to true if it is using a bambulab printer.

I am not sure why the slicer is using klipper estimation over the BBS in the flatpak version. I also looked through your patches and did not spot anything related that could cause this issue.

I am currently digging through bambustudio code to understand where this condition could be set, as my ender 5 plus is not a BBL printer ... but it seems the klipper estimator produces strange results .. The configuration file seems ok though ..

    "header": "BambuStudio 01.08.04.51",
    "models": [
        {
            "model": "Bambu Lab X1 Carbon",
            "nozzle_diameter": "0.2;0.4;0.6",
            "vendor": "BBL"
        },
        {
            "model": "Creality Ender-5 Plus",
            "nozzle_diameter": "0.4",
            "vendor": "Creality"
        }
    ],

Au fait, j'ai vu que tu etais aussi francais, donc GG encore pour le port ;)

[grm]

It seems that determining if the printer is BBL is done in BambuStudio.cpp line 4467 based on the model name of the printer (e.g. if the printer name starts with Bambu Lab) :

                                bool is_bbl_vendor_preset = false;

                                if (!printer_model_string.empty()) {
                                    is_bbl_vendor_preset = (printer_model_string.compare(0, 9, "Bambu Lab") == 0);
                                    BOOST_LOG_TRIVIAL(info) << boost::format("printer_model_string: %1%, is_bbl_vendor_preset %2%")%printer_model_string %is_bbl_vendor_preset;
                                }

but i did not spot the string printer_model_string in the logs

EDIT : I renamed my printer to 'Bambu Lab XXX' in order to try to make the evaluation produced true, but it does not have any effects and the produced gcode seems to be still the klipper one.

[hadess]

; estimated printing time (normal mode) = �z�"^F^?

This looked like garbage, either binary data or freed memory.

Except that, trying to look for the code you mentioned, and which I couldn't find:

sprintf(buf, "; model printing time: %s; total estimated time: %s\n", get_time_dhms(machine.time - machine.prepare_time).c_str(), get_time_dhms(machine.time).c_str());

I saw this: https://github.com/bambulab/BambuStudio/commit/9b47f26f20ce938a531be59742e5c1c4908ee245 which still isn't in v1.8.4 which we're shipping.

The appimage worked because either it's running an older version, or it thought it was generating GCode for a BambuLab printer.

[hadess]

There's a backport for the fix in #9...

Au fait, j'ai vu que tu etais aussi francais, donc GG encore pour le port ;)

and an Amazon wishlist linked in the README ;)

[grm]

The appimage worked because either it's running an older version, or it thought it was generating GCode for a BambuLab printer.

The version is older i guess, klipper support has been added 2 days ago and the log let me thinks that the condition is not there yet

[grm]

and an Amazon wishlist linked in the README ;)

I can only see my delivery adress ... did you specify one in your wishlist on your side to receive anything ?

[hadess]

I can only see my delivery adress ... did you specify one in your wishlist on your side to receive anything ?

Oops, fixed, thank you for noticing.