The proper way to register a bug is to report it on the GitHub page as an “issue”. You’ll need to register an account on GitHub.
It would be a kindness to accept bug reports in this forum thread and copy them to GitHub on behalf of the poster.
The latest version on GitHub now includes a button to manually modify the device IP.
When I developed this software, I gave the AI an instruction: all bug fixes should have corresponding records kept in traps.md. Haha.
No worries, you can also reply with bugs under this topic. I will log in once a day to check for any bug reports.
Of course, it would be even better if you could report issues on GitHub and give me a star!
Thank you!
i am not sure why this code is still showing. i can upload and print from bambu studio, but i cannot manually click on it on the u1 side. it says unrecognised file and there is no print button.
added onto the problem i found out that is it doesnt seem to upload the filament selection in the gcode files. hence it couldnt print because it doesnt show up.
from the app it shows like this. that is probably the problem im facing right now. files uploaded into the gcode doesnt reflect any filaments required. hence the program stopped there.
- Upload failure may be due to network issues or other reasons; sometimes gcode uploads fail. You can try uploading again. I will attempt to fix this.
- Gcode cannot be recognized on the Orca/U1 device end: That is correct.
Currently, gcode generated by Bambu cannot be directly selected for printing on the U1 device side or in Orca. It can only be used within Bambu. Essentially, this is because Orca cannot recognize the identifiers within the gcode, preventing proper filament matching.
If you really want to use it on the device side, you can use the “Gcode Conversion” feature, which can convert Bambu’s gcode into Orca’s compatible mode.
Although I don’t think it’s very meaningful, you can give it a try. Be sure to check the gcode for any bugs.
ohhh so i cannot directly print off the program? i didnt know that. i was thinking this plugin would let it work.
so technically i still have to save and export it out and use a converter to convert to u1 3mf then can print?
You can print directly from this software. However, it doesn’t work on the U1 device interface, nor does it work with the official Orca slicer. The G-code is incompatible.
3MF is a format for 3D models.
G-code is the code that printers can recognize. However, Bambu and Orca use different G-code formats, which can cause issues with device recognition.
Bambu currently has a rich ecosystem, and I created this compatibility pack so that everyone can directly print many models from the Bambu community.
That’s all.
So actually bambu also uses a proprietary 3mf file as well that uses different color formats than the standard 3md file. A community member released a GitHub with a conversion tool. I took that code and went one step further and made it not only convert 3mf from bambu or any other multi color 3mf file and it auto creates a 3mf file with full spectrum color mixing already figured out for you. It’s still beta but you can check it out at .https://colorblend.ainlight.com/ Feedback would be much appreciated so I can improve upon it!
1 Like
July 17, 2026 Update:
A new branch named linux-support (planned to be merged into the main branch in the future) has been added: GitHub - VitasGuo/BambuStudio-SnapmakerU1-Compat at linux-support · GitHub
We welcome everyone to test it and provide feedback and suggestions for improvement!
1 Like
Hi, have you considered submitting the project for our Innovation Fund:
1 Like
That works. But I don’t feel like I have the time to write papers or anything like that. I just want to make it comfortable for myself to use.
1 Like
Where can I find the install instructions so I may try this plugin?
I’m having a problem where, even though the G-code has been converted, it still produces these errors when changing heads.
Unable to parse move ‘G1 X141.419 Y242.086 F5400,000000’
Or can you only use solid colors with the mods?
The multi-color model can also be sliced normally. However, due to Bambu’s restrictions, there might be minor issues with temperature control for multiple hotends, but it is certainly usable. Could you please share your G-code files (both before and after conversion)? This might help us pinpoint the issue.
I have theoretically verified the G-code conversion many times, but errors can still occur. The AI suggested that this might be related to the language you are using. If possible, please provide the language setting used in your Bambu Studio. Thank you.
Here is the advice provided by the AI:
Diagnosis Conclusion: Yes, it is a punctuation issue (comma vs. period)
Root Cause of the Error
F5400,000000 — The F value uses a comma as the decimal separator, whereas the G-code standard requires a period .. The firmware cannot parse 5400,000000 (which was intended to be 5400.000000 mm/min).
This is Not a Bug in Our Compatibility Package
I reviewed all G-code processing code:
-
[convertGcodeContent](file:///C:/Users/nishu/Documents/SOLO/3D-printer/BambuStudio-SnapmakerU1-Compat/bridge-node/slice_agent.js#L1170-L1499) (Bambu Studio → OrcaSlicer conversion):
- Only replaces
; FEATURE:→;TYPE:([L1487](file:///C:/Users/nishu/Documents/SOLO/3D-printer/BambuStudio-SnapmakerU1-Compat/bridge-node/slice_agent.js#L1487)) - For G1 move lines, it only performs filtering (keeping/deleting), without modifying the numeric content ([L1393-L1432](file:///C:/Users/nishu/Documents/SOLO/3D-printer/BambuStudio-SnapmakerU1-Compat/bridge-node/slice_agent.js#L1393-L1432))
- Any F values generated by itself are hardcoded integers (
F10000,F18000,F360) with no decimal points - There are no calls to
toLocale*,toFixed(except for displaying file sizes), orNumber.toString()that would introduce commas in the entire file
- Only replaces
-
[patchGcodeContent](file:///C:/Users/nishu/Documents/SOLO/3D-printer/BambuStudio-SnapmakerU1-Compat/bridge-node/slice_agent.js#L410) also does not touch the numeric format of F values.
-
traps.mdhas no records related to locale/commas.
The True Source: Bambu Studio Slicer’s Locale Bug
G1 X141.419 Y242.086 F5400,000000 is produced when slicing in Bambu Studio on a non-English Windows locale (German/French/Russian/Spanish/Portuguese, etc., where commas are used as decimal separators). Bambu Studio’s C++ floating-point formatting is affected by setlocale(LC_NUMERIC), outputting 5400.0 as 5400,000000.
Note that X141.419 Y242.086 uses periods — Bambu Studio uses different formatting methods in different code paths (this is an inconsistency in Bambu Studio, not our problem).
Why the Error Persists “After Conversion”
Because our conversion does not fix the locale format — the original G-code is F5400,000000, and after conversion, it remains F5400,000000. The conversion only changes layer markers and start/end G-code procedures, leaving the numeric content of move lines untouched.
Why the Error Occurs “Only During Tool Changes”
The firmware exposes the issue when parsing subsequent G1 moves after executing T0/T1 tool changes. Earlier commands like PRINT_START are macros and do not trigger parsing; the error “Unable to parse move” only appears when actual G1 moves are processed.
Recommendations for Users (Solved Without Code Changes)
- Simplest solution: Change your Windows regional settings to English (Control Panel → Region → Formats → English (United States)), restart Bambu Studio, and slice again.
- Or force the C locale in Bambu Studio’s startup parameters.
- Long-term solution: We could add a single regex line
s/F(\d+),(\d+)/F$1.$2/ginconvertGcodeContentto fix commas in F values (this would be a compatibility patch, not a bug fix) — but since you mentioned not changing code, let’s first ask users to adjust their locale.
2 Likes
Hi all! Thank you so much for sharing this awesome project! It has already made a huge quality of life improvement for me!! I was hoping you could consider two issues. Maybe you have discussed them, but I did not see any comments in this thread.
-
The first item is that the gcode from Bambu does not trigger early pre-heating of the next nozzle swap and instead it waits until the current color is finished and then starts to heat the next nozzle. this causes the toolhead to sit and wait for a temp increase from 70c to 220c. The snapmaker will instead trigger a pre-heat command about 30 seconds before the end of the current color’s layer. It would be great if this dwell could be eliminated as a print with 1k tool changes might add 2-3hrs of wait time.
-
The second issue is if you have say 8 colors in your filament list and your print uses colors 2,4,6,8 when you go to the print confirmation on the device tab, it will only list the first 4 colors in the filament list with no obvisous method to change them. In this situation the colors for the unlisted #6 and #8 positions may not change the color correctly. Below are a couple images:
This slice uses colors 1, 4, 5, 6 but when i go to the confirmation screen, it will only list colors 1-4.
Please see how this confirmation screen shows the wrong colors that are not part of the model.
Any thoughts, comments, or advice would be greatly appreciated.
Thanks!
1 Like
First issue: Bambu does not generate the G-code for switching; this can only be resolved through subsequent G-code conversion or repair. The directly generated G-code cannot support preheating. This is likely a known issue, which I believe I have documented in the open-source files on GitHub.
Second issue: The second issue can potentially be fixed. This seems to be related to a mapping function.
I have attempted to fix the second issue: automatic G-code detection and recognition. The fix has been pushed to the main branch on GitHub. You can verify whether it has been resolved.
However, I had previously abandoned the main branch and have only been maintaining the remote branch. For convenience, I have merged both versions. You can download the latest version.
Thank you so much for digging deeper into this! I have also been working on issue 1 with some help from GPT and currently we have a modified bridge that can incorporate tool pre-heating. I am testing prints now to verify and so far it is working great. Will follow up soon. I don’t really know much about using branches and forks through gitnub, but will try to work it out :-).
Again, thank you so much for starting this amazing project!!
Thanks VitasGuo for putting this together! I’ve been using it and worked on a fork to add a few things I wanted:
-
Automatic nozzle preheating so there is less waiting at color changes.
-
Filament selection that only shows the colors actually used in the print
-
All toolheads allow you to select any of the available filaments and there is no concern about the order. Your model could use filament numbers 2,5,8,9 and they can easily be mapped to tools 1-4.
-
The ability to map more than one project color to the same toolhead. If your project uses more than 4 filaments, you can easily point the excess filaments to any of the 4 toolheads.
-
Allows 5+ filament prints by using a pause after a color is completed, you can swap out the filament on the machine with a new color and continue to print with a 5th (or more) color. NOTE: You are responsible to add pauses in the right places otherwise the slicer WILL NOT stop.
-
In the print dialog, it WILL warn you if you are using 5 filaments without a pause giving you the option to cancel and add pauses or to continue without them which might be ok.
-
Implemented automatic gcode conversion when using Print or Upload, so there is no need to manually export, convert, and upload the gcode.
I’ve tested it on my U1 and the preheating has made a big difference. There are still some limitations with starting uploaded files from the touchscreen, so those are noted in the release. You can upload 4 color files and start them from the machine however if you have 5+ filaments, it will upload, but the print will fail after the #4 toolhead check. I tested this directly using SnapMaker Orca and even the original slicer suffers this same error.
Here is the fork if anyone wants to try it:
This builds on VitasGuo’s work—all credit to him for the original project! I’m new to the GitHub side of this, so feedback is welcome 