Adding support for the enraged rabbit carrot feeder (ERCF)

Alex.cr

@pfn
Thanks for the feedback.

@alex-cr the first error is legitimate, you cannot use runout sensing during printing if the sensor and print extruder are not on the same board.

I knew this was the case, what I didn't realize is that your software was turning the encoder into a filament monitor. Neat feature but I will skip it for now. I now realize that you are reading the individual pulses and your software routes around that limitation. Nice work!

With regard to SBC mode... I do not know how this could be worked around...

I have a work around. Comment out the line below and everything works great!:

echo >{global.ercf_selector_file} "; AUTOGENERATED FILE DO NOT EDIT"

Good luck and thanks for being a willing guinea pig!

Not a problem, thanks for contributing the lions share of the work!

I have most of the initial setup completed now. Had to work through issues with the selector axis losing steps. Took me a while to figure that out...

Alex.cr

@pfn

In regards to the encoder trigger rate. Are you having any issues with the rate at which the trigger#.g file fires to accurately count the filament as it loads to the extruder? It appears to be VERY feedrate dependent.

I am wondering if this is another issue with SBC. Ill have to dig through the upgrade notes again and see if I can find anything on max trigger values.

pfn

@danzaywer logic wise, it's pretty similar, there's a few things I could handle better that isn't done yet: detecting a jam in the selector, and handling mid-bowden stoppages.

I'd also like to use stall detection for loading, but it seems my ERCF build isn't robust enough to grip filament sufficiently tightly to stall

There's no endstops in my implementation, so there's no motor reassignment for the extruder loading move, it's just a single 2 axis move G1 Ex Vx Fy the encoder detects whether filament was successfully loaded into the extruder.

Another difference is that state is saved, so that reboots and power cycles assume the ERCF remains in its previous position, homing is really only done once, and otherwise to recover from selector jams.

pfn

@danzaywer until I decide to use Tx to switch tools, the current mechanism is to add machine specific toolchange gcode: M98 P"ercf/lib/load-tool.g" Tx

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.

You can buy D shafts from powge on aliexpress.

In the US, you can buy 5mm precision round stainless rod from McMaster which you would then have to grind yourself.

pfn

@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

I did initial development of the ERCF gcode on duet2, but never tried with feed rates greater than 40mm/s (having jamming problems really got in the way of going any faster).

On the duet3, I haven't tested to see how fast the encoder can trigger, however, I load at 150mm/s completely reliably, the pulse count generally matches what I expect for an ~800mm bowden. Again, a less than perfect build prevents me from loading at much faster than 150mm/s with any level of reliability.

This might be another sbc difference, it seems triggers would have to be invoked from the duet to the sbc for processing, and that appears to introduce latency that would limit the max pulse/second rate.

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