Adding support for the enraged rabbit carrot feeder (ERCF)

pfn

@alex-cr I prefer to make it so that there are some sane defaults and users can modify only what is necessary in settings, less clutter for the user to look at.

That's not to say that a user cannot edit globals.g and must edit settings.g -- one could completely ignore settings.g; but I feel it's a disservice to do so. One would have to repeat the setting twice (the initial declaration is guarded by if exists) and that adds to clutter.

The only inelegance of this approach is the selector_slotX_pos problem that requires a user to edit globals.g to remove slots if using a 4 cart system

PCR

@dc42

this would be the sammy pinout

this should work?

dc42

@pcr you need both a Tx (normally Pad 0) pin and a Rx (any pad) pin on the same UART to control the TMC drivers. You've chosen to use PA12 for the Tx pin, so one option would be to use PA13 for the Rx pin and move STEP_1 to another PA pin. Or you could use PA20 and PA22 for the UART as we do on the tool board.

Another constraint is that every pin used as a digital input pin (including the two DIAG inputs from the TMC2209s) should be on a separate EXINT number.

You can choose whether to run the SAMC21 at 3.3V or 5V. The TMC2209s must use the same voltage on the VCCIO pin.

o_lampe

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

the kit I got has a less-than-straight D-shaft

I studied the build instructions and to me it seems, it's pretty easy to bend the D-shaft during assembly.
There are some points were it can go wrong.

Wrong height of the center bearing support
Wrong length of the smooth rod assembly
or just from handling the lower assembly without the top assembly

pfn

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

o_lampe

@pfn
I didn't want to blame you, but prepare for the new d-shaft.

pfn

new demo video:

https://www.youtube.com/watch?v=N4DiK5DVftM

Alex.cr

@pfn

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

pfn

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

pfn

It prints!

alt text

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 has M98 R1 set.

Some other tuning needs to be done around final filament parking and documenting how this could be used by more folks.

PCR

@dc42

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

Alex.cr

@pfn

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, Untitled picture.png

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:
Untitled picture2.png

Curious what your thoughts are. Thanks for the hard work!

pfn

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

PCR

@pfn think @T3P3Tony mentioned that in some further release they will allow a simple runout switch without the extruder on the same board. Something for 3.4 stable?

danzaywer

@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

danzaywer

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

danzaywer

@pfn
where you buy D-shaft rod?

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.