I trying to figure out if it possible using AMS (Lite) when exporting and printing GCODE files (manually transferred to SD card). I’m using A1mini. When I select 3MF file, there is an option “Use AMS”. But when GCODE file is selected there is no such option and the entire AMS related lines in the GCODE seams to be ignored.
Is multi color printing with exported GCODE not possible generally? Or have I missed something?
FYI: I’m asking because in my specific use-case there are some constrains and I have to use explicitly GCODE files and can’t use 3MF.
I can only speak for X1C, but when I put a gcode file on its SDC and print it from the touch screen, I get a dialog similar to what you’d get in Bambu Studio: Checkboxes for ABL, AMS, Timeshift and even the filament matching stuff.
I may be missing the issue. Sorry.
To be clear, you upload a g-code to the SD card, and when printing, the printer misinterprets the g-code and doesn’t use the AMS (uses external spool?) or uses the AMS but ignores the filament swap?
Or doesn’t it show you an option to select the AMS, as in the slicer, and you didn’t try to print?
If the latter, you can evaluate the g-code file in Bambu Studio and preview it to confirm the use of multiple filaments. If true, the printer will read and interpret the g-code correctly.
Sorry for being unclear in my post.
I slice an object in slicer (BBS or Orca) and assign a PLA spool from one of AMS slots.
Then I export a 3MF and start from SD card using printers screen. Printer asks if I want use AMS. I confirm. Print starts, AMS load filament, leveling, printing, print ends, AMS retract filament.
Same procedure, but this time using GCODE file. I execute the file using screen UI. Printer doesn’t ask about AMS. Print starts, AMS does nothing, leveling, printer stops reporting error because no filament is loaded.
This is what I mean saying printer ignores AMS related gcode lines.
By opening the g-code file in Orca, can you confirm that it entails the selected filament(s) from the AMS? Since .3mf works, you may compare the g-codes of both files. Or use the .3mf embedded g-code file to print (for testing, not as final solution).
Yes, AMS related gcode lines are in the file. I even extracted a gcode file from the 3mf and it turned out to be exactly the same as the exported gcode file (I compared both files using npp code editor).
When you say “export to 3mf” do you mean like “Export plate sliced file” in the slicer? Maybe the A1 is no different from the X1C then, because what I meant with my comment was the above: Whether using “send” from the slicer or exporting a “plate sliced file” and putting it on the SDC, I get a “.gcode.3mf” file which will let me choose filament at print time.
I think I have had this happen once(!) but didn’t quite understand what I did differently. In this case, how did you produce the gcode file? Did you extract it from that “.gcode.3mf” and then send that file only?
I think I recall Orca had this a bit differently. Maybe that’s it? I’ll check it out.
I get a “.gcode.3mf” file which will let me choose filament at print time
Yes, on 3MF (or let it call .GCODE.3MF) I also have the ability enabling AMS on print start. My particular constrain is that I limited to using GCODE files only (not packaged into 3MF).
Would be great if you could test a “plain” gcode file exported from BBS or Orca on your X1. On BBS you can get it by going to “File > Export > Export Gcode”. In Orca it’s available in the upper right drop down.
That was it - I think we’re on the same page now. In both slicers, if you use “Send”, the file that lands on printer’s card will be called “.gcode.3mf” and is consequently a 3MF file also including G-code.
If you instead “Export plate sliced file”, you will get the exact same thing (but on your local computer) and Bambu Studio will still call it “.gcode.3mf” while Orca just calls it “.3mf” even though it also contains G-code.
The third option is currently only available in Orca: “Export G-code file”. I take it that one is what does not work for you, and likely what also did not work for me that once. I can confirm it contains identical G-code to what is included in the 3MF alternative. I was confused for a while because it’s larger than the .gcode.3mf, but that is only because the latter is zip compressed.
So the X1C seems to have the exact same problem as the A1. Apparently something in the 3MF (.gcode.3mf) is needed for getting that AMS functionality.
For me, .3mf and .gcode are different files, independent of the content.
According to @Dill the issue relates to the .gcode file, which I can export from Bambu Studio (not only available on Orca).
No, I have not found any solution. I ended up modifying my selfmade software to make it work with 3mf as well. I don’t think it’s a bug. It’s just one of multiple (quite obvious) limitations applied to gcode use.
Could you share more detail on the modifications you made and how you’re creating a .3mf file? I’ve been able to unzip a .3mf file generated by Bambu Lab and view the gcode but I haven’t found any way to re-zip it into a .3mf file. Some people say the .3mf is the same format as .zip but when I re-zip the the unzipped .3mf (without making any changes), and change the extension to .3mf it throws errors in slicers and doesn’t print. The original file opened without issue. I was hoping I could unzip the 3mf file, insert my gcode, resin and print. Thanks!
Actually this should work. Just like @JonRaymond mentioned above, 7zip does it quite well. I can imagine that your issue was an acidantely changed folder structure. When you unzip 3mf (eG. somemodel.3mf) it will create a folder called “somemodel” with all the subfolders and files. When you zip the folder back again, it will add this directory on the top level and instead somemodel.3mf/Metadata/Plate_1.gcode it will now be like somemodel.3mf/somemodel/Metadata/Plate_1.gcode. This could be one possible issue which comes into my mind. Another reason could be a usage of different compression algorithm by your zip software. But if you do it like @JonRaymond described none of these issues should appear.
Another point is, the Metadata folder contains also Plate_1.gcode.md5 file. This hash file secures the actual gcode file, so when it become modified the system can notice it and refuse processing the 3mf. However it’s not yet “signed” , so it still can be recalculated and edited manually to make the 3mf file passing the validation. However after @JonRaymond talked about his workflow I’m not sure if this md5 file is actually used by printers os for validation. Have to test it though.
Edit: it’s very likely that the modified 3mf will only work when sending it to printer via slicer (BBS or Orca) becauss the slicer possibly recalculates the md5 before sending. When sending the modified 3mf file manually via FTP or SD CARD it will probably be necessary to adjust the md5 file as well.
edit2: just tested it. Regardless the wrong md5 file it works both ways, via slicer and via SD card. So looks like printers firmware currently ignores the md5 file.
This is great. I’ll test tonight when I get home. Thanks @JonRaymond and @Dill ! The folder point is good. I was zipping the folder rather than the files contained so adding another layer to the structure. I’ll test whether I can print from SD card or through the slicer. Either way works.
Not sure what your use case is and if this information is relevant for you, but I figured out that the crucial file for AMS functionality is Metadata/slice_info.config.
If this file doesn’t contain the full list of used filaments, printer will not change the filament, regardless of what is in the GCODE. In worst case it will just heat up to 250° and stuck.
Hi, I just saw the video by “Factorian Designs” about Automating a Bambulab Printer. I have an A1 with AMS Lite und made it work, that the printer pushes the print of the bed.
The only thing is, I can´t get it doing the next print. If I modify the gcode by just copying the working gcode for my model, so it starts printing again on its own, I can´t check a box for using AMS.
So I would be happy, if any one has a solution to use AMS lite with modified gcode files on an A1.