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