Auto Endless Spool Groups with GCode-Preprocessing
Closed this issue · 6 comments
I'm already 9 Months working on my Vcore500 with an ERCF+ Self Developed Spool RewinderBox.....I Got Lots of stuff to work by myself, thanks to your flexible software without messing with your python code, all just with your extensible macros. i'm surprised how well this works already. we already had a discussion about endless spool mode, for the moment i accepted the extra waste the current solution produces. but your gcode processor got me thinking.....first i wanted to implement something that detects if it's a single color or multicolor print but i pushed it to the future.
but after i forgot to reset my endless spool groups, i thought it could be nice to be able to assign the groups automatically by material and color....i'm quite new to jinja2 stuff.....chatgpt's output (at the end), sounded promising, but produced errors. i'm not sure where the problem is, since jinja2 should support dicts, lists and tuples, but surely, getting this to run would be a nice addition for the MMU_START_SETUP macro....
basically i'd say: if filament and color are the same over several gates, group them automatically.+ maybe an mmu_parameter to say group manually or automatical, and even ignore_colors, if you wanna get rid of old spools
i'm working with orcaslicer, and just always have my 9 filaments in the software and keep them updated. i'm dreaming a bit of connecting orcaslicer, spoolman and happyhare to automatically sync their informations, but thats gonna take some time...but automatical group assignment for endless spool would already be a nice ans quick addition that reduces headaches (i discovered the behaivour cause of 2 faulty pregatesensors)
here's chatgpt 4's code....kinda surprised, 3.5 was completely helpless(logically material_list and color_list should get the info from mmu_vars? - i also recognized the wrong syntax from the comments - tab formating got lost in the issue):
https://chatgpt.com/share/66f6d284-4a9c-8003-8136-d3bc4760cdcf
{% set material_list = ['PLA', 'PLA', 'ABS', 'PLA', 'ABS', 'PLA'] %}
{% set color_list = ['Red', 'Red', 'Green', 'Red', 'Green', 'Blue'] %}
{% set unique_pairs = [] %}
{% set group_counter = 1 %}
{% set groups = [] %}
{# Loop over the material_list and color_list #}
{% for material, color in material_list|zip(color_list) %}
{# Create a unique key for material and color pair #}
{% set pair = (material, color) %}
{# Check if this pair has been encountered before #}
{% set group = none %}
{% for upair, ugroup in unique_pairs %}
{% if upair == pair %}
{% set group = ugroup %}
{% break %}
{% endif %}
{% endfor %}
{# If not seen before, assign a new group number #}
{% if group is none %}
{% set group = group_counter %}
{% set unique_pairs = unique_pairs + [(pair, group_counter)] %}
{% set group_counter = group_counter + 1 %}
{% endif %}
{# Append the group number to the groups list #}
{% set groups = groups + [group] %}
{% endfor %}
{# Generate the MMU_ENDLESS_SPOOL command #}
MMU_ENDLESS_SPOOL GROUPS={{ groups|join(',') }}
greetings, you're doing great work here
This is an interesting idea and actually if you look at the new "automap" feature here: https://github.com/moggieuk/Happy-Hare/wiki/Tool-and-Gate-Maps#---automatic-tool-to-gate-ttg-mapping
You will see it is similar in thinking. Actually while implementing that there was a discussion about automatically creating endless spool groups at the same time -- it isn't much of an extension of the work.
While this could be done completely in a macro, logic like this is far far easier in python.
Actually quite nicely implemented already...happens quite often that i try do build something thats already built 😉
So basically there's a gate map for the printer, a temporary slicer tool map, and the mapping....although it is possible to set PA, flow, temp, fan, all these values in macros, they are still easier and more comfortably managed in the slicer, especially when you do precice calib for every used filament....ok i could do very precice filament names and defign all these parameters, but thats a hazard as long as these profiles don't get synced.
Is there a way already to make the slicer tool map persistent? The grouping got confused while testing when the gatemap didn't match the slicer tool map...."no matching filament found in gate 8"
The slicer tool map is created on print start and will exist until the next print or the MMU (Happy Hare) is reset via reboot or command.
For testing you can look at a mmu.log extract the various calls to MMU_SLICER_TOO_MAP and put into a macro for quick setup.
Just remember the role of each map. The "gate map" is what is physically loaded on the MMU, the "slicer map" is what the slicer thinks. The "ttg map" can match slicer tool to MMU gate, but you will still have two sources of information for things like filament color.
I do think the best implemenation to this would be to extend the AUTOMAP functionality on the MMU_SLICER_TOOL_MAP"command with say AUTOGROUP=1. Then if supplied, whatever the matching method employed is can be used to dynamically form the endless spool groups
so finally i think i slowly start to understand how your system works....i tend to systemize my filament supply anyway, so this is gonna be obsolete quite soon....but just hypothetically: i have 1 spool matte white extrudr pla nx2 colorized with titanium oxide, and one other spool with other stuff. at least i will need different PA, and FLow Values, Maybe even temperature. the TTG map will confuse them if i don't use Filament Name as strategy. Since the Gcode Preprocessor doesn't get the Names from the Slicer, i Assume it uses the ones Written in mmu_vars.cfg.
I tested and Adapted some code in your gcode preprocessor wiki page, this serves for the moment as a workaround for the missing GUI Elements in fluidd and lets me conveniently manage my gates in the slicer - called before anything else in the machine g-code.
additionally passing filament names would be even nicer since then i could use the auto ttg filament strategy. but even this solution ensures correct auto endless spool groups every time without sacrifizing features from persistence level 4....
luckily, even if i just send a single color print, it always sends the info from all setup tools with it.
MMU_OVERRIDE_GATES COLORS=!colors! MATERIALS=!materials!
`
[gcode_macro MMU_OVERRIDE_GATES]
description: makes sure the Gate Color and Material matches the Information in the Slicer Tool Map.
gcode:
{% set COLORS = params.COLORS|default("")|string %}
{% set colors = COLORS.split(",") %}
{% set MATERIALS = params.MATERIALS|default("")|string %}
{% set materials = MATERIALS.split(",") %}
MMU_TTG_MAP RESET=1
{% for color in colors %}
{% set tool = loop.index0 %}
#{% set gate = ttg_map[tool] %} # Make sure map to correct gate in case of TTG map
MMU_GATE_MAP GATE={tool} COLOR={color} # Register the filament color against correct gate in gate map
{% endfor %}
{% for material in materials %}
{% set tool = loop.index0 %}
#{% set gate = ttg_map[tool] %} # Make sure map to correct gate in case of TTG map
MMU_GATE_MAP GATE={tool} MATERIAL={material} # Register the filament material against correct gate in gate map
{% endfor %}
`
Sorry, only had a couple of mins to read the first part of your message.... the filament names can be retrieved from the slicer. Add FILAMENT_NAMES=!filament_names! to the print start: https://github.com/moggieuk/Happy-Hare/wiki/Slicer-Setup#---start-g-code
It was an add with v2.7.0 I think.
Will try to read the rest tomorrow, but it looks like you know what you are doing..
oh, nice! that actually solves the problem, thanks. it's missing in the gcode preprocessor wiki
greetings