So it does! That must have been fixed in the latest version, because in previous versions, that button did not populate the slots. It merely updated the filament dropdown lists in include the current filament in the AMS as a selectable option.
I’d cross that off the list, but I am still unable to edit the original post.
@BrotherC, can you please change @MortalWombat’s top post to a wiki and/or manually issue him a higher trust level? It’s clear this user is here to contribute for the good of Bambu Lab judging by all the work he has done to document this over the last few months.
Timelapse video file names should include the file name from the model printed (in addition to timestamp) for ease of identification. Timelapse thumbnail should be taken from the last frame of the timelapse itself, not from a separate image captured after the bed has been moved to the bottom of the enclosure and the print is out of sight. See here.
The flow calibration DB and write-up are bang-on. As a dev reading it, it’s a good chunk of work but they can split this by adding a local one in the slicer and indicating which spool has it set. This can reset when that spool is unloaded. Ie: save values by AMS slot in a ‘dumb’ way
They can then make it so the calibrations can be assigned to an object which defines a spool (when you load the spool back u can select which one it was from your created spools - so save the calibrated ones to a local db and can assign them to ams slots)
Then make an online repository which can sync the local ones and create a DB of calibrations that can be imported by brand/color/type
@BrotherC, I haven’t heard back in over a week. A lot has transpired since then and we still haven’t seen any acknowledgement or action on this item. A friendly reminder: Could you please up @MortalWombat’s role so he can edit his post and/or make his top post a wiki? Thanks.
Any chance to get an official reply from dev dept re the above ? They should at least acknowledge and comment here and there and even provide timeline for improvements, no ? I know it can be challenging at the moment in China, but…
There is one issue with the sync feature. If the AMS slots are not populated sequentially (e.g. slots 2 and 4 have filament and slots 1 and 3 are empty), the sync button will populate the slicer with filaments 1 and 2. The current workaround is to make sure that the AMS is populated left to right.
@Madmax
I don’t think, this is a bug, it is working as it is. because it is not possible in the Slicer to have only one Filament and this filament have the number 4. it is beginning with 1.
so if you have 3 filaments in your ams you got 1,2,3. the order in your ams is correct but the empty slots are not count.
I think this is incorrect. In the Slicer you can see all 4 slots, slot 1 to 4. When printing you select which slot that you want to print from. So you need to be able to say “print from slot 4” even when slot 3 is empty. It would make no sence to in the slicer call slot 4, 3 just because you left slot 3 empty.
@Flashy_DE
Agreed, it’s not really a bug as long as you are aware of how it acts. It appears you can’t add an “empty” filament slot in the slicer. Not really a problem with 1 AMS. I could see problems with multiple AMS. e.g. If you remove the filament from slot 6 of 16 and sync it, slots 6 thru 15 will have the wrong colors/materials in the slicer. Not a major problem, but something to be aware of. (My friend just had this problem with 2 AMS units. He removed the spool from slot 5 and then wondered why it didn’t print the correct colors).
@Flashy_DE@BjornE
Now what is really interesting on further inspection, it appears the colors map to the correct slots in the AMS even if the slot number is wrong in the slicer. I suppose the colors need to match exactly?
Not sure I think this is the best way to show it anyway. @Flashy_DE was correct that it seems to just show the filaments that are available regardless of slot. To me this still is not really correct. The correct way should be that if you have a AMS and put filament in slot 1,3 or 2,3 or 1,4 etc it should sync and show all 4 slots and the correct filament in the correct slot. But grey out the 2 slots that are empty.
So in your case you would see 1: greyed out, 2: PLA red, 3: greyed out, 4: PAL yellow
Or at least in the slicer menu where it shows the available filaments show 2,4 instead of what it shows in your screenshot where it says 1,2 for red and yellow.
At least it seems that it works when you select to print so it is more a GUI-issue then
I don’t agree with the way the slicer handles the AMS currently. As the software knows if an AMS (or multiple AMSs) is present, it should default to displaying that number of slots, whether they’re full or not. I know different people have different workflows, but I have to imagine that most people are slicing models to print on demand, and they’re being sliced to print with materials currently loaded.
For most of the people most of the time, the correct behavior is for the slicer to show the correct number of slots and their current status. If somebody wants to manually modify the contents of a slot to set up a future print job, that’s fine. But I strongly suspect that is the exception rather than the rule in practice. As such, the software should default to “this is what is currently in the printer”.
I do suggest, for the sake of happiness for everybody, please go into studio’s github section and start an issue or request or whatever can be done there and secondly open a ticket, so that BL is aware and hopefully will react soon. I do believe that none of the officials does follow here on a regular basis. At least I am not seeing much from them. Let’s try @BrotherC ?
Please note that we are following the forum, but we are unable to dedicate a lot of time to reading all threads and be up to date with all discussions.
The best way to report a bug or a suggestion, is by going to the correct section of the forum (Bambu Lab Software), and sharing it according to the guide. This will allow our R&D team to spend their time efficiently and consider every post.
Opening multiple tickets or requests on github, or multiple threads for the same request might not be as efficient, as it can generate more time spent for an issue that was already considered. A single thread for a proposal, with comments around that bug report/proposal is much helpful for the team.