Adding support for the enraged rabbit carrot feeder (ERCF)

danzaywer

@pfn
I redesigned one of the pieces of the selector to insert an endstop with a steel ball just to have the feedback necessary to understand any anomalies, in this way I can know if the wire is present up to the extruder if it is stuck in the tube or if it is short to portray it. As soon as I have time I will make a further modification to have both endstop and encoder (or laser filament sensor). I also save the state by storing the active tool in a variable and write to a file that is loaded by config.g. the U axis homing after a certain number of changes (set with a local variable) because the smuff carriage does not flow very well ...

danzaywer

@pfn
I have three macros:

TFREEMASTER.G invoked by all tfreex.g
TPREMASTER.G by tprex.g
TPOSTMASTER.G by tpostx.g

you could enter in tpostmaster:

M98 P "ercf / lib / load-tool.g" T{state.currentTool}

as far as temperatures are concerned, I manage them with 6 global variables:
global ToolF; first layer temperature tool
global ToolC; temperature toolchange
global ToolT; first layer temperature tool
global ToolS; standby temperature
global bedH; first layer bed temperature
global bedB; temperature bed
these variables are set by "/ filaments / <filament-name> /config.g", where I can possibly also insert pressureadvance and more, the template I use is

0:/filaments/ABS/config.g
;-----------------------------------
var firstlayertemp=240
var layertemp=235
var standbytemp=180
var toolchangetemp=234
var firstlayerbed=103
var layerbed=95
;-----------------------------------
set global.toolF=var.firstlayertemp
set global.toolT=var.layertemp
set global.toolS=var.standbytemp
set global.toolC=var.toolchangetemp
if global.isfirstBedHeat && global.setBed
	set global.bedH=var.firstlayerbed
	set global.bedB=var.layerbed
	set global.isfirstBedHeat=false

i don't need load.g and unload.g of the filament
the temperature of the tool and of the bed is set by a macro that I inserted in the start gicode of the slicer and at the tool change. In superslicer I put this:

;Start G-code
M83
set global.slicer=3
set global.layercount=0
{if wipe_tower}set global.slicerwipe=true{endif}{if !wipe_tower}set global.slicerwipe=false{endif};wipetower
T[current_extruder]
M703
M98 P"/sys/DEFAULTS/heatup.g"
M116
;end start

;BEFORE_LAYER_CHANGE
G92 E0.0
{if layer_num>0}set global.layercount=[layer_num]{endif}
;[layer_z]

;AFTER_LAYER_CHANGE
;SET LAYER COUNT
{if layer_num<2}{if layer_num>0}M98 P"/sys/DEFAULTS/heatup.g"{endif}{endif}

;TOOL CHANGE G-CODE
T[next_extruder]

for CURA I have to initialize the global.layercount to -1 in the start and then pass in post processing script:

set global.layercount = {global.layercount + 1}

of course you have to set ALL the temperatures of ALL the materials to 0 in superslicer to let the printer manage everything!

in this way and setting the tools in config.g with:

M584 X0 Y1 Z2:9 E3:3:3:3:3 U4 V8 P5

M563 P0 S"E1 " D0 H1 F2                						; Define tool 0 P=tool number, D=driver number, H=heather, F= fan
M563 P1 S"E2 " D1 H1 F2                						; Define tool 1
M563 P2 S"E3 " D2 H1 F2                						; Define tool 2
M563 P3 S"E4 " D3 H1 F2                						; Define tool 3
M563 P4 S"E5 " D4 H1 F2                						; Define tool 4
;M563 P99 S"SUPPORT" D5 H2 F2                				        ; Define tool 99

I can have the materials assigned to each tool and with a flag variable that disables the execution of the tool change macros outside of printing I can change the material from the web interface to any tool (obviously not for the one currently loaded, for that I disable the flag to physically perform the unloading and loading).
in start.g the tool actually loaded is always selected.
the slicer only deals with the management of the fans as they are strictly linked to the gcode and the material, I don't think it can be left to the firmware to manage it ...
my only current problem is that when i change filament with ATX off the printer tries to heat the tool and i have a temp fault, i could not understand where i went wrong as the heater should stay off, as soon as i have time i investigate, for now it is a manageable problem.

danzaywer

@pfn
sorry if i ask a stupid question, what is the purpose of

M42 P {global.ercf_servo_num} S0

when do you engage and disengage the servo?

pfn

@danzaywer that is to turn the servo off after making its move. The servo is moved in engage and disengage macros

danzaywer

@pfn is a good idea to turn servo off during engage? I think it will cause lost of grip on filament....

pfn

@danzaywer on the ercf, once the servo reaches past a position, it will be locked into place, so there would be no loss of grip

Alex.cr

@pfn said in Adding support for the enraged rabbit carrot feeder (ERCF):

There's also some problems around properly changing temperatures if changing material type that comes with not using Tx, I'm not sure if I want to cave and use the tool notation for changing filaments.

My vote is to leave any Tx out of the equation. I should think we can write a filament change macro that can account for temps without having to build 4-9 different tools in the config file. That or leave it to the slicer and make sure the necessary G10 lines are over there. That is my plan at least.

@pfn said in Adding support for the enraged rabbit carrot feeder (ERCF):

@alex-cr on my duet2, for testing, I was able to reliably get 70-100 pulses per second in some standalone experiments
https://forum.duet3d.com/post/252836

Interesting I missed that part of the forum post. I even chimed in at the end... I am for sure getting different trigger/pulse events that I would expect. I have a few changes I need to make to my ERCF and then I will be testing more.

pfn

@alex-cr the main problem with slicers is that they will output G10 Px Stemp where x is the tool number (for the case of mmu, the virtual tool)--this is at least the case for superslicer, and possibly prusaslicer.

danzaywer

@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

Alex.cr

@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 Stemp where x is 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.

pfn

@alex-cr superslicer will always emit G10 Px Sy regardless 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.

pfn

@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

pfn

@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)

danzaywer

@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

pfn

@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

danzaywer

@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!

danzaywer

@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

pfn

@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

danzaywer

@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.

pfn

@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.