Adding support for the enraged rabbit carrot feeder (ERCF)
-
@alex-cr said in Adding support for the enraged rabbit carrot feeder (ERCF):
My vote is to leave any Tx out of the equation.
if I can express my opinion I think that sticking to the standard firmware logic can only bring advantages. Tx invokes in order Tfreex-Tprex-Tpostx, just leave the unused ones empty and invoke for example the macro of the tool change in Tpostx. Don't reinvent things that already exist, especially if they are done well. I currently have a fully functional Smuff V6 system (apart from the hardware limits of smuff) with temperature management and relative PID made by firmware, all made with standard structures in about 20 total macros
-
@pfn said in Adding support for the enraged rabbit carrot feeder (ERCF):
@alex-cr the main problem with slicers is that they will output
G10 Px Stempwherexis the tool number (for the case of mmu, the virtual tool)--this is at least the case for superslicer, and possibly prusaslicer.This can be overcome by just putting 'G10 P0 Stemp' in the tool change G code to override superslicer from putting in other commands.
That being said, you and @danzaywer are probably correct in that 'Tx' commands are probably the correct way to go to be more slicer agnostic and follow convention.
-
@alex-cr superslicer will always emit
G10 Px Syregardless of any toolchange gcode.I'm generally not a fan of using Tx still because it pollutes the /sys folder. Right now, I'm just experimenting with creating the tool but not ever actually using the tool.
My printer is temporarily down as some belts and wires got destroyed. So I won't be working on this until after the holidays are over, most likely.
-
@danzaywer said in Adding support for the enraged rabbit carrot feeder (ERCF):
@alex-cr said in Adding support for the enraged rabbit carrot feeder (ERCF):
My vote is to leave any Tx out of the equation.
if I can express my opinion I think that sticking to the standard firmware logic can only bring advantages. Tx invokes in order Tfreex-Tprex-Tpostx, just leave the unused ones empty and invoke for example the macro of the tool change in Tpostx. Don't reinvent things that already exist, especially if they are done well. I currently have a fully functional Smuff V6 system (apart from the hardware limits of smuff) with temperature management and relative PID made by firmware, all made with standard structures in about 20 total macros
I'm not a huge fan of creating all the tXXX.g macros in /sys -- if simply creating the tools in config is enough to allow temperature control, I will likely use that approach
-
@danzaywer said in Adding support for the enraged rabbit carrot feeder (ERCF):
for CURA I have to initialize the global.layercount to -1 in the start and then pass in post processing script:
why do you need a layercount? this is also available from object model...
in general, I'm not a fan of doing RRF filament temperature management, I still have a purge line at the beginning of my print, and moving a purge line logic into filament settings is very convoluted and inelegant. It may be something I investigate more as I become more fully setup with MMU printing, but at the moment, it conflicts with my design goals. My design goal is to make mmu(ercf) support drop in and easily removable. There should be minimal calls into ercf from regular RRF settings (the only line should really be the macro call for init.g); additionally, it should be easily moved to another printer with minimal manual configuration (should require user changes to only settings.g)
-
@pfn said in Adding support for the enraged rabbit carrot feeder (ERCF):
why do you need a layercount? this is also available from object model...
because I was unaware of the existence of job.layer and I built it by myself ... thanks for the tip! one less global variable in memory!
@pfn said in Adding support for the enraged rabbit carrot feeder (ERCF):
I still have a purge line at the beginning of my print, and moving a purge line logic into filament settings is very convoluted and inelegant
why would you move purge line logic into filament management? I think it continues to be managed by the slicer, I don't use it, I use a skirt line for filament priming but I can verify. The purge tower works for me without problems
-
@danzaywer said in Adding support for the enraged rabbit carrot feeder (ERCF):
why would you move purge line logic into filament management? I think it continues to be managed by the slicer, I don't use it, I use a skirt line for filament priming but I can verify. The purge tower works for me without problems
because purge has to come after heating, and that depends on the filament being set, which comes after start gcode. and single material prints don't have any purge behavior -- that's one thing I need to figure out how to detect from the print job
-
@pfn said in Adding support for the enraged rabbit carrot feeder (ERCF):
@danzaywer said in Adding support for the enraged rabbit carrot feeder (ERCF):
why would you move purge line logic into filament management? I think it continues to be managed by the slicer, I don't use it, I use a skirt line for filament priming but I can verify. The purge tower works for me without problems
because purge has to come after heating, and that depends on the filament being set, which comes after start gcode. and single material prints don't have any purge behavior -- that's one thing I need to figure out how to detect from the print job
Yes, is all correct and is all working well to me!
-
@pfn said in Adding support for the enraged rabbit carrot feeder (ERCF):
because purge has to come after heating
In start gcode I put M703 after Tx then temperature macro
-
@danzaywer said in Adding support for the enraged rabbit carrot feeder (ERCF):
In start gcode I put M703 after Tx then temperature macro
How does the start gcode know which filament is loaded? M703 can only heat with the correct filament loaded (and I actually have M703 in tpost already).
I suppose this isn't an issue outside of the first job with a new tool if the filaments in the tool don't change, but I'm still changing filaments frequently per tool (pla to petg and abs), and that state that rrf keeps is going to be frequently out of sync
-
@pfn first of all https://duet3d.dozuki.com/Wiki/Slicing_recommendations
In prusaslicer or superslicer start gcode put T[current_extruder]
In toolchange gcode put T[next_extruder]
At job end i leave filament in hotend.It is also stored in a file parsed in config.g by tpostx.g macro. When new job start if T[next_extruder] is the extruder already loaded then reprap firmware do nothing, otherwise toolchange macros begins.I also store tool T-1 during unload (tfreex.g) so if powerfailure happens with no tool selected firmware know it at restart.
You have to put M703 into tpostx.g and after T[next_extruder] in start gcode otherwise if tool is already loaded RepRapFirmware not run toolchange macro and m703 inside it is not applied, of course it depend to what m703 do, in my case it Set global variables related to temps of tool selected. -
@danzaywer said in Adding support for the enraged rabbit carrot feeder (ERCF):
In prisaslicer or superslicer start gcode put T[current_extruder]
I'd meant the filament loaded into a particular tool would be out of sync, not the tool number, that aspect is already handled. The problem is that any T0 T1, etc don't know what filament is loaded. There's no way to know it from start gcode. RRF can guess based on previous state (filament M701 gcode during filament changes from the slicer) but it cannot know if filament was swapped out of the tool.
-
@pfn when you change filament in tool you simply click on tool name in DWC interface and select "change filament". At this point firmware know what filament is present into tool until you swap it with a new one, also after reboot... DWC do all the magic... I fear my English is not so good to explain but trust me : Duet do it!
-
@pfn whit my configuration I can slice a file to print with T2 in with I have petg, after print I change T2 filament to pla and reprint same file with pla temps , only issue I have is fan speed, I'm working on it but , I can set max speed in m703 but don't know how tell to firmware to handle bridging situation. My intent is to have gcode independent from filament loaded in tool.
-
@danzaywer said in Adding support for the enraged rabbit carrot feeder (ERCF):
when you change filament in tool you simply click on tool name in DWC interface and select "change filament".
I understand this, but I have always forgotten to do this, I heavily rely on the slicer to set filament for me. Why set it in multiple places, it's not an optimal workflow
-
@pfn I change slicer often, not printer, so I prefer that is the printer to handle things. Another reason is that if I have a file sliced I can print it in any material without reslice it. I name sliced files with tools involved in it.
-
@pfn
Other reason to let the printer manage temps:- slicers put temps command after Tx command so is not possible to manage temps prior to return to print position after change
- prusaslicer/superslicer have bed temps for firstlayer and other layers but put into gcode the instruction relative to actual selected material so if you have, as exemple, ABS and PETG print with ABS fist layer:110, ABS other:90, PETG first layer: 80, PETG other:70, first object of list in ABS (the one with high temps) then slicer set first layer temp to 110, change to second tool , set second layer temp to 70 and ABS detaches...
-
Hi, is there a working solution for ERCF? The GitHub at the start of this thread seems abandoned
It will be great to stick to RRF & DWC, but if it's not supported in future it might be a reason to switch to klipper
-
@Inlinebrother I was working on a refreshed version of pfn's config earlier this year. But then I managed to formate the wrong drive when doing a clean Windows install and lost all that work (+ alot of other projects).
After that i kinda dropped off for a bit, I still got all my notes etc. anf plan to take it up again in the future. But seeing how much TLC the klipper addons have been getting the last year it's not something one person can keep up with porting over to RRF unless it's his full time job.
-
@Inlinebrother I asked @pfn on the RRF Discord server (https://discord.gg/uS97Qs7) if he was still using it. His reply:
I haven't updated it to latest and whatnot, it did kinda work before
I don't have a filament sensor in the toolhead, it's entirely driven by the ercf encoder
so because of the way filament monitors work on rrf, if you have a can-fd toolboard, you need to run the filament monitor from the ercf to the toolboardIan
