Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Adding support for the enraged rabbit carrot feeder (ERCF)

    Scheduled Pinned Locked Moved
    Accessories and Add-ons
    12
    64
    11.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • pfnundefined
      pfn @Alex.cr
      last edited by

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

      Alex.crundefined 1 Reply Last reply Reply Quote 0
      • danzaywerundefined
        danzaywer @Alex.cr
        last edited by

        @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

        pfnundefined 1 Reply Last reply Reply Quote 0
        • Alex.crundefined
          Alex.cr @pfn
          last edited by

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

          Voron2.4/Duet3 SBC+6HC+3HC+1LC+1HCL(x2) - Delta/Duet2 Wifi - CubePro/Duet2 Wifi+Duex5 - Laser/Duet3 Mini5+ - Cel Robox - U̶p̶3̶0̶0̶+/D̶u̶e̶t̶3̶ ̶6̶H̶C̶+̶LC1̶ - F̶T̶-̶5̶/̶D̶u̶e̶t̶2̶ ̶W̶i̶f̶i̶ - S̶o̶l̶i̶d̶o̶o̶d̶l̶e̶

          pfnundefined 1 Reply Last reply Reply Quote 0
          • pfnundefined
            pfn @Alex.cr
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • pfnundefined
              pfn @danzaywer
              last edited by

              @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

              1 Reply Last reply Reply Quote 0
              • pfnundefined
                pfn @danzaywer
                last edited by

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

                danzaywerundefined 1 Reply Last reply Reply Quote 0
                • danzaywerundefined
                  danzaywer @pfn
                  last edited by

                  @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

                  pfnundefined 1 Reply Last reply Reply Quote 0
                  • pfnundefined
                    pfn @danzaywer
                    last edited by

                    @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

                    danzaywerundefined 2 Replies Last reply Reply Quote 0
                    • danzaywerundefined
                      danzaywer @pfn
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • danzaywerundefined
                        danzaywer @pfn
                        last edited by 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

                        pfnundefined 1 Reply Last reply Reply Quote 0
                        • pfnundefined
                          pfn @danzaywer
                          last edited by 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

                          danzaywerundefined 1 Reply Last reply Reply Quote 0
                          • danzaywerundefined
                            danzaywer @pfn
                            last edited by 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.

                            pfnundefined 1 Reply Last reply Reply Quote 0
                            • pfnundefined
                              pfn @danzaywer
                              last edited by

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

                              danzaywerundefined 2 Replies Last reply Reply Quote 0
                              • danzaywerundefined
                                danzaywer @pfn
                                last edited by 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!

                                pfnundefined 1 Reply Last reply Reply Quote 0
                                • danzaywerundefined
                                  danzaywer @pfn
                                  last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • pfnundefined
                                    pfn @danzaywer
                                    last edited by

                                    @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

                                    danzaywerundefined 1 Reply Last reply Reply Quote 0
                                    • danzaywerundefined
                                      danzaywer @pfn
                                      last edited by

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

                                      danzaywerundefined 1 Reply Last reply Reply Quote 0
                                      • danzaywerundefined
                                        danzaywer @danzaywer
                                        last edited by

                                        @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...
                                        1 Reply Last reply Reply Quote 0
                                        • Inlinebrotherundefined
                                          Inlinebrother
                                          last edited by

                                          Hi, is there a working solution for ERCF? The GitHub at the start of this thread seems abandoned

                                          It will be great to stick to RRF & DWC, but if it's not supported in future it might be a reason to switch to klipper 😞

                                          Exerqtorundefined droftartsundefined AlexKidundefined 3 Replies Last reply Reply Quote 0
                                          • Exerqtorundefined
                                            Exerqtor @Inlinebrother
                                            last edited by

                                            @Inlinebrother I was working on a refreshed version of pfn's config earlier this year. But then I managed to formate the wrong drive when doing a clean Windows install and lost all that work (+ alot of other projects).

                                            After that i kinda dropped off for a bit, I still got all my notes etc. anf plan to take it up again in the future. But seeing how much TLC the klipper addons have been getting the last year it's not something one person can keep up with porting over to RRF unless it's his full time job.

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA