Adding support for the enraged rabbit carrot feeder (ERCF)
-
@o_lampe it's certainly a possibility that this is self inflicted. I already have 3 more rods on the way to help make sure it's less likely I end up with a bent rod if that's the case.
-
@pfn
I didn't want to blame you, but prepare for the new d-shaft. -
new demo video:
-
My tip forming isn't tuned yet, but at the moment it's a 10mm extrusion at 5mm/s, followed by unloading 80mm at 5mm/s; this part is actually really what takes longest
In regard to tip forming, I have been working on tuning this while my kit comes in.
Below is what is working for me in ABS so far if you are interested. I am using a Mosquito and LGX.;called to unload filament from the nozzle to support the ERCF G1 E4.0 F500 G1 E-10.0 F1500 G4 S1 G1 E-10.0 F300 G4 S1 G1 E-20.0 F700 G1 E-60.0 F1000
-
@o_lampe I think most of the stalling issues are related to poor dimensional accuracy/warping on my abs prints, I have no enclosure, so stuff isn't perfectly accurate.
-
It prints!
Still some issues to resolve:
cooling moves performed by superslicer immediately before changing filaments cause RRF to constantly flag that there's a filament-error: "tooLittleMovement" is detected. I don't know how to get around this yet. I'll try to generate a print job that replicates the cooling move and see how this triggers RRF into erroring.Errors during filament swapping while printing don't necessarily get handled well,
M98 R1
doesn't seem to behave exactly as I expect, sometimes my macros appear to continue executing to the end (macroRestarted
is false) and silently failing even though my full call stack hasM98 R1
set.Some other tuning needs to be done around final filament parking and documenting how this could be used by more folks.
-
Just update the schmematic. I compeltly forgot about hte RX TX thign honestly. Last time i made a board wtih Stepper UART contoll it was the same mistake
-
I just got my ERCF installed and working on tuning now. I am just getting started but most things seem to be working. I am having two issues and curious what your thoughts are.
I am running the following setup, SBC+6HC+3HC+1LC. The ERCF has everything using the 3HC. Extruder on the 1LC. Running 3.4.0beta6 (2021-11-06 11:38:57). I am also using your most recent set of uploads to github as of 3 hours ago.
Here are the two alarms,
I am hoping the first one doesn't matter too much and corrects itself based upon when the ERCF extruder is selected. This may or may not be true and may need some rethinking if people do not have the encoder on the same board as their main extruder?
I think the second error seems like an SBC issue? @chrishamm ? Are you running on an SBC or standalone?
Here is the .g file that it references:echo >{global.ercf_selector_file} "; AUTOGENERATED FILE DO NOT EDIT" echo >>{global.ercf_selector_file} "set global.ercf_selector_pos = " ^ global.ercf_selector_pos echo >>{global.ercf_selector_file} "set global.ercf_extruder_loaded = " ^ global.ercf_extruder_loaded
And a screen shot of the variables:
Curious what your thoughts are. Thanks for the hard work!
-
@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.
A filament sensing workaround will need to be developed. Should be pretty easy, a macro called from daemon.g while a print is running and reconcile pulse count with extruded distance. And leave the encoder trigger always enabled.
For now, you can comment out the M591 of filament-sensing.g; filament runout sensing is not necessary for normal ERCF operation. It's an added bonus of having an ERCF. Runout sensing would be necessary for a future endless spool mode which has not yet been implemented.
With regard to SBC mode, it's something I, personally, won't use until a killer application becomes available. The second error is likely due to SBC. I do not know how this could be worked around. There's likely some fixes that would need to be done to support the sbc gcode parsing disparity.
Good luck and thanks for being a willing guinea pig!
-
-
@pfn
Hi, I am happy to have found your configuration and I want to study it. I have been using a Smuff V6 for some time and am printing the ERCF to exchange it. My general configuration is the following:
duet 2 wifi + duex5 powered with ATX (5v rail on duex)
endstop on smuff instead of the encoder
endstop in the extruder (afterburner with v6)
servo
V axis for feed
U axis for the selector
the logic I use is (not exaustive):
Load- check presence of endstop smuff
- check presence of endstop extruder
- possible error management (half-finished wire or selector not free)
- home selector if not homed and move to position {((global.selectorOffSetfromEndstop) + (state.nextTool * global.toolDistance))}
- servo on
- switch "V" endstop to smuff endstop high
- extrude to the first endstop
- switch "V" endstop to stall detection
- extrude to stall
- switch "V" endstop to extruder endstop high
- assignment of motor "E" and motor "V" to the V axis
- extrude V (double motor) up to second endstop
- servo off
- restore one motor for V axis and one for extruder
- switch "V" endstop to none
- extrude to hotend
Unload
- macro execution tip
- servo on
- unload with E and V fixed distance to bring the filament out of the extruder (there is no need for endstop so no motor reassignment)
- switch "V" endstop to smuff endstop low
- while endstop not triggered
- Unload with V to endstop in Smuff
- if more than 2 try send message to continue try so I can remove clogg
- switch "V" endstop to none
- Unload with V a fixed quantity to free the selector (50mm for SmuFF)
- servo off
if you want I can post my files but they are not well commented
-
@pfn
I didn't understand how you invoke the macros during the tool change, do you have to insert the macro call in the slicer? -
@pfn
where you buy D-shaft rod? -
@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...
-
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.
-
@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.
-
@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.
-
@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/252836I 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.
-
@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 ... -
@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 is0:/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.