I wonder if there are any existing setups where the main aim is to have material backup rather than multicolor capability. I understand that the default way of operating the chameleon is with predetermined tool change commands. A filament runout isnt programmed at a specific point unless a rough approximation is done and a tool change is made to extend the filament supply.
That requires micromanagement but is still a step towards a more intelligent solution. Ideally I would like to be able to use the device as material backup for large builds when specific materials not available in large spools are to be used.
Is there a way for the chameleon to sense a runout before the printer's runout sensor and feed new filament from behind to keep the process going?
The 3DChameleon is not designed for that scenario. The gcode is in control of the system and there is no way for the 3DChameleon to communicate to the printer. Remember, our interface is solely through the switch, which is triggered by the gcode to initate a color change. The color changes are encoded in the gcode and is predetermined at slicing prior to printing. Now... with that said, if you can turn things around, you can actually connect the 3DChameleon to a processor that can control the switch (or GPIO) at any point as long as that processor has access to filament sensors for each of the 4 filaments prior to it going through the 3DChameleon.
Platforms like Klipper or Octoprint are capable of monitoring those filament sensors and triggering "macros" to dynamically inject the tool changes at that point. But, as I said, we do not support it natively.
Bill