When filament not loaded it prints with a different color

I am calling this a bug, I was printing a two color job. I did not notice one of the colors was not loaded. Instead of stopping end triggering an error like it should have done, it went ahead and selected a different color, completely wrong color for the job. Software should not be making these kind of decisions. If the job calls for gradient blue, and a light blue filament and one of them is not loaded it should error out and display the problem on the screen until the operator fixes the issues or selects a different filament. THE PRINTER NEVER SHOULD MAKE THAT KIND OF DECISION AUTOMATICALLY. If a color/filament is not available the printing should stop, trigger a large error message on the screen and let the operator resolve the problem.

For example, if a job calls for Blue and Red and one of those colors are not available the job should stop with a BIG errror message, in fact the job should not be allowed to start if all the jobs colors are not available.

@dch2023 I get what your saying, and 100% agree this would be great, but from my testing and understanding I think I have figured out the below - and knowing it , you can easily work around it.

Its not really operating on colours, past the slicing stage or ‘making decisions’ AFAIK, its just using what it already knows based on your setup to build a filament availability list for the job - defined by ‘selection’ of SLOTS to use. So yes it “looks” like it relies on colours, but it doesnt really, so no warnings are forth coming. Note: You do get warnings for customised filaments that arent correct, obsurcure filament gcode that may be saved in a project thou.

As far as I know, if your using AMS - once sliced, its not saving \ sending the “colour” its sending the AMS slot # (and any correspeonnding paramers, like Temps, Flow etc). E.g. If you have Red loaded physically in AMS slot\bay 2, yet in software your AMS in slicer #2 Filament might be set to Gradient Blue. If you dont resync\sync or correct your physical loaded filament, or change the filament choices in Slicer - and you just send it - its sending SLOT 2 - with those temps, flow etc - in the gcode - and the printer does what its told annd prints filament loaded in SLOT 2 (which is actually RED).

Some Smarts like Bambu RFIDs annd other things like Custom filaments and filament library help that ‘colour’ hygine and in terms of the RFID does help limit these ‘mis prints’… but my experience (and I may be wrong) - its colour blind once it gets to gcode\printer, its just AMS slots \ external spool it sends. No cameras, it cannot “see” the colour - it gets told SLOTS to use - so , if your AMS sees a matching filament - based on its rules.

So - how does the AMS have a matching colour - when it Shouldnt!! A number of variables, its not synced, filament spool changed since last sync, previous used slot had the same but not resnyced, Vendor and material type in another slot matchesfrom a previous job etc.

I had a similar example to yours, happen to me and did reverse test to prove it

  1. Put 2-4 different cololurs in AMS itself - non-bambu\No RFID
    e.g. White, Matt Blue, Green, Red - PLA spools etc
  2. Load 2-4 diferent objects you can colour, print by object is easiest.
  3. Selecting the same colour filament Eg PLA White in all the Filament\AMS slots in the slicer
  4. Then ‘paint’ the other 2-4 parts with the different filament\slot numbers
    eg - select Part 1- change to Filament 1, Part 2 - set to Filament 2 etc -you get the picture.
  5. Do NOT sync or refresh Filaments\AMS
  6. Slice and send it.

This is where I want ( and I think you do too? ) an option to resync or double check actual AMS physical filaments - when was the last sync, If filaments different than a preivous job - have some kind of popup eg Is AMS colour 1 really blue , Colouyr 2 - red etc etc- (and you should be able to opt out of this too)

  1. Now watch as 2,3,4 parts - print in the different colours, even through in your slicer as the same whte PLA and each of the 2-4 parts are displayed as white in Slicer from Step 3, but the remember, its different filament SLOTS - and we havent sycned.
    — (You can stop job as soon as you see the colour change for Part #2 :slight_smile: )

IMPORTANT- THIS BEHAVIOUR CAN ALSO CHANGE DUE TO FOLLOWING

  • Resync\Syncing - I do this EVERY job now, iresspective of doing it previously.
  • Print Priority order\default colour set on the plate can change the “first” filament SLOT, I routinely check and adjist this as required per job.
  • Loading \ unloading\swapping filament can change the “order” of slots\colour\filament. again - it just sends a “Slot” number, but differnet sequence compared to what your SLICER looks like.
  • Forgettinng to Turning off ‘Use AMS’ but slicing from external spool filament? - Watch the start loading from the External spool, do all that manual bit - thenn watch as it unloasd the externnal spool and print changes to the priority plate Filament, pulled from the AMS (sometimes gives an error)

AMS Automatic Filament refill - SPECIAL MENTION - see below.

  1. Automatic filament failover - is that turned on for the AMS? that changes things too.

Example (If Automatic AMS Refill is turnned on)
a) If the SLOT 3 is empty - it will fail\error if there are no available filaments trhe same in the AMS (based on slicer knowledge)

HOWEVER - we told the slicer filaments, it was all same WHITE PLA correct?

b) So, If the SLOT (say #3) is empty - but you havve sliced the SAME colours in all slots, eg WHITE on all 4 SLOTS, it WILL fail over to another similar SLOT (Say #4 - but physically Red actually resumes and prints) - ie the GCode, just knows that Slot 3 - has a ‘refill backup slot’ in Slots 1,2,4 (as initally we told them its all white). Does that make sense?

Another way I tested, In Slicer - set Slot 2 - to be a PLA filament, yet physically load TPU or PETG , and watch it try to print that “SLOT” tuned to PLA paramaters … and watch the amazing job it does with your TPU or PETG :stuck_out_tongue:

(Kidding, Dont do that… you might get a bad clog or ruin you bed … or somethinng ugly - but … its possible to do, and the prionter just sends it (As long as you dont force a sync or change to TPU\PetG etc)

Be very happy for someone else to confirm\deny\test and prove me wrong… but this is what my limited testing has shown. I havent examined gcode or done of that. just done test prints and wasted filaments to work it out.