Adding support for the enraged rabbit carrot feeder (ERCF)

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.

danzaywer

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

danzaywer

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

pfn

@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

danzaywer

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

danzaywer

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