Who Has Moved to RRF3

Discussion in 'Getting Started' started by Paul Arden, Jul 12, 2020.

  1. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    My TC has been idle for a while but I am soon going to go through the Hemera upgrade since all of my replacements have arrived. Since I basically have to do the commissioning steps again anyway I’m thinking I’ll likely move up to RRF3.

    I notice the official E3D repo is still on 2 for it’s config @Greg Holloway are there any plans to move the initial default configuration to RRF3? Would also be great to see a Hemera version of the config but I don’t imagine there are too many differences.

    There has been quite a lot of comments from users who are running RRF in various release candidate incarnations so I’d be curious as to how many TC users are now running the current release RRF3 and happy with it (or not).
     
  2. Greg Holloway

    Greg Holloway Administrator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    967
    Likes Received:
    619
    There is intent to go to RRF3, however I haven't planned a time to do it yet. With the COVID palava time is limited in the worhsop.

    It is pretty simple once you get your head around the new pin naming. Technically you don't have to change anything other than to add pin labels....
     
    Paul Arden likes this.
  3. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    165
    Likes Received:
    32
    I use RRF3. 3.1.1

    My config files are located here:
    https://github.com/Nibbels/e3d-toolchanger-config
    But please note that I only use 3 DirectDrive Toolheads (The last tool T3, hemera, is on the way to me) and that anyone using those files should be reading through the configuration line by line to check if the gcodes are suitable for the specific toolchanger.
    Read the readme.
    Dont think this is a default setup. I tend to change everything to have my workflow as I like it. ...

    :)
     
    Paul Arden likes this.
  4. blarbles

    blarbles Well-Known Member

    Joined:
    Aug 10, 2019
    Messages:
    100
    Likes Received:
    64
    Greg says "simple" but I keep up on the forums and it seems like there are quite a few things to tweak. I have not updated to RRF3 but would like to. Since I have not wrapped my head around the new pin names it would be nice to have a RRF2 with the Tool Changer used XX, RRF3 with the Tool Changer and same wiring uses YY.
     
  5. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    450
    Likes Received:
    204
    Paul Arden likes this.
  6. Michael Pearson

    Joined:
    Apr 1, 2020
    Messages:
    13
    Likes Received:
    6
    I updated to RRF3.1.1. There is a good amount to change but I did not find it that hard to do. That being said you need to have good attention to detail. I took my basic config and printed it out. Then I spent a couple weekends going through the “Upgrading to RRF3” page, the RRF 3.0 release notes, and the RRF3.1.1 Release Notes. All the info is there including a pin name chart, and a good description of all the changes and GCode. Then I sat down with VS Code and started making all the changes I had noted. Once I felt like I had everything figured out and coded correctly I went through the update process. Note, you must go from 2.05 to 3.0 and then to 3.1.1.

    The biggest change that you need to pay attention to IMO is that the Z endstop cannot be defined as both an endstop and a probe. So you need to make that change in config and you also need to remove the z homing moves and add a G30 to homez.g. Otherwise you will crash.

    The biggest issue with posting configs is we are all tinkering and fine tuning, using different strategies for slicers and retraction, different hot ends and extruders. So it gets crazy trying to take someone else’s config and use it. It is great for reference but you need to make sure that you understand the differences between that machine and yours.
     
    Paul Arden likes this.
  7. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    I’m wondering about the Z-endstop situation you mention @Michael Pearson since the G-code reference has the following example:

    RRF2

    M558 P7 H5 F120 T3000 ; Z probe connected to Z endstop input

    RRF3

    M574 Z0 P"nil" ; no Z endstop switch, free up Z endstop input
    M558 P5 C"zstop" H5 F120 T3000 ; Z probe connected to Z endstop input


    Obviously these are not TC specific, just examples from the G-code guide. It suggests they are equivalent ways to specify this and that would imply the RRF3 way above would be used for sharing the pin for z-endstop and z-probe.
     
  8. Michael Pearson

    Joined:
    Apr 1, 2020
    Messages:
    13
    Likes Received:
    6
    Correct it is not TC specific.

    Under RRF2 the probe could be defined as both a probe as shown in the M558 command and as an endstop with a M574 Z1 command whicH would define a z endstop at the low end.

    Under RRF3 it cannot be defined as both. The M574 Z0 command means no endstop. and the M558 command defines the probe.

    Once you do this you need to be sure when homing that you dont simply send the probe towards the bed with G1 commands as you would if you had an endstop because it will crash. You need to use a G30 command to probe the bed to set your home position.
     
  9. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    450
    Likes Received:
    204
    You NEVER need to use the Z probe as if it is an endstop. When users do this, it creates support issues on the forum, because the trigger height of the Z probe isn't taken into account when it is treated as an endstop. That's why we have removed the facility to configure it this way.

    If you try to do a G1 H1 Z move but no Z endstop is configured, it won't crash the head, it will report an error.
     
    Nibbels likes this.
  10. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    I think the confusion comes from the difference between "using the Z-probe as if it is an endstop" and "Z probe connected to Z endstop input" which I think many people will read as the same thing. To be honest I still find the explanations somewhat confusing. So in the example I gave above for RRF3 is there a z endstop or not?

    So what I am reading from @dc42 is that you can either have a Z-probe or a Z-endstop but not both (regardless of pins, from what I see this has nothing to do with pins). Further, if you attempt to home z using G1 and no Z-endstop is configured (necessarily true if you have a Z-probe configured) you will get an error and you should be using G30 instead for this purpose?

    If Z-endstops and Z-probes are mutually exclusive in RRF3 I think it would be good to say exactly that. Of course I may be interpreting this all wrong still.
     
  11. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    450
    Likes Received:
    204
    It's entirely possible to have both a Z endstop and a Z probe. Some people use an endstop and Z-max and also a Z probe. However, they are likely to disagree on where Z=0 is.

    What's wrong is to configure a Z probe as if it is a Z endstop. OTOH there are a few printers that use the Z probe for X homing. That's the only reason that we allow a Z probe to be used as an endstop.
     
  12. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    In which case what is the correct way to configure the Toolchanger, where there is 1 physical switch which was previously used both for probing operations and for homing the Z-axis. In RRF2 the following was provided by E3D:

    M574 Z1 S2 ; Set Z endstop probe
    M558 P7 X0 Y0 Z2 H3 F360 I0 T20000 ; Set Z probe type to switch, the axes for which it is used and the dive height + speeds
    G31 P200 X0 Y0 Z0 ; Set Z probe trigger value, offset and trigger height


    I've just been looking through yours and @Nibbels configs which are a little different, though both define a probe with no endstop. I guess my question then would be what actually happens when homing Z in that case. Looking at homez.g in both configs it looks like instead of basically intentionally ramming the bed until the endstop triggers (as in the RR2 config for TC), G30 is now used instead which is a single Z-probe.

    So, for TC in RRF3 there is no Z-endstop and the Z-probe is used for determining the Z origin (along with whatever per tool offsets etc are applied). At least that is how I am understanding it. This does all seem to be covered in both of your configs, I am just trying to get my head around it, think I am getting there.
     
  13. Michael Pearson

    Joined:
    Apr 1, 2020
    Messages:
    13
    Likes Received:
    6
    Paul

    That's what I was referencing that needs to be changed. The code you posted has the same switch defined as both an endstop and a probe. That configuration works under RRF2 which is what it was made under. Under RRF3 it will not work and the command needs to be changed to

    M574 Z0 ; No Z endstop.

    M558 P8 C"pin-name" H3 F360 I0 T20000 ; Set Z probe type to switch, P7 is no longer used in RRF3 replace pin name with zstop or whichever pin you connect your switch to. make sure the parameters work with your setup.

    Then you need to replace the G1 Z move in your homez.g to be g30 to probe the bed to set home.
     
  14. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    165
    Likes Received:
    32
    In comparison to my old printers:

    The consequence of having a single z probe as reference is that I first probe my Z origin at some specific (X,Y).
    Then on the found level (of Z) the actual probing for the auto bed leveling is performed once.
    That means that the autobed leveling is only valid if I use the same (X,Y) to probe the Z (when "homing" Z).

    I did once read about the compensation taper
    https://duet3d.dozuki.com/Wiki/Using_mesh_bed_compensation#Section_Compensation_Taper
    upload_2020-7-18_15-56-39.png

    -> I did not want overextrusion anywhere. So the point where I want find the "homeZ"-Origin is the highest point of my bed.
    [In case I want to use Compensation Taper]

    My other printers do compensate the material flow. Duet does not. That is why I did care for this tiny detail. A limit of 5% is good. I did choose the same limit once.
    For now I did turn off M376 with H0. Because Auto Bed Compensation Issue - Tool offset
    Maybe maybe CncKitchen did choose the point of probing at the lowest point of the bed instead of the highest and thus got overextrusion by design. I dont know. In case he did home in the middle that is probably what did happen.

    Correct my if I am wrong on details.
     
  15. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    450
    Likes Received:
    204
    Are you sure? Can you direct me to a reference that says that your other firmware definitely does that? It's very hard to do properly, because the amount of extrusion adjustment needed varies along the length of the move.
     
  16. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    165
    Likes Received:
    32
    Yes, it was not programmed by Repetier / Conrad Electronics initially so I implemented it by myself.

    It was hard to understand and do but I hacked it into the firmware motion system as a parallel process. The same way as the bed leveling fade out works in my printers firmware. But it works!
    The leveling is programmed in a way that the first layer is following the shape of the bed exactly. No stretching at layer 1.
    Then from layer 2 on the fade out starts. This has to end somewhere at a specific height of Z. Then the part should be flat and the leveling has to end. (Z_leveling_end -> like M376 Hxx describes.)
    [I did define that the corresponding Z_leveling_max is to be calculated from the Z_max (highest point of the auto bed leveling points) minus Z_min (the lowest point). So that not more than 5% are stretched in each layer at maximum. -> No M376 needed]

    Step1:
    The calculation of the needed additional amount is here:
    https://github.com/Nibbels/Repetier...2362a6d7268e2672c0c13e5/Repetier/RF.cpp#L3182
    https://github.com/Nibbels/Repetier...2362a6d7268e2672c0c13e5/Repetier/RF.cpp#L3284
    This function constantly writes a factor (example: 1.05 => 105% needed) into a variable. The factor is the needed flow factor which is valid at this time of movement at this specific Z(X,Y). === percentage of layer-to-layer stretching

    Step2:
    That variable is processed by the stepping interrupt.
    To keep it easy and simple: What I basically do there is to maintain a global variable which holds a sum of tiny float increments. The sum increases with each e-step.
    (Like 0 +0.05 +0.045+0.035+0.045+0.05 ...)
    Each time the summed value is >= 1.0f the single additional step is put out additionally to the normal e steps.
    https://github.com/Nibbels/Repetier...a6d7268e2672c0c13e5/Repetier/motion.cpp#L1470

    That means we have an error in time but not in integral flow. I thought alot about a better solution but a single step all 20 steps is nothing. It seems that the physical flow of the material flattens the error perfectly.

    How did I test this?
    I printed parts with some transparent sample filament and looked at the reflections of the material. When the reflection did not change after the leveling height anymore then the code was perfect :)

    This picture is without e compensation: 21,755g
    Screenshot_18.jpg

    With e compensation: 22,030g
    Screenshot_1.jpg

    Comparison of the shiny parts.
    Screenshot_2.jpg
    Here on the old pictures we still see one single line of "underextrusion". That was a bug because at the last layer I forgot to compensate. After the fix the material was at the same density on all layers.

    Greetings
     
    Michael Pearson likes this.
  17. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    I have bitten the bullet and performed my RRF 3.1.1 update. The update from 2 to 3.0 went smoothly however after doing the subsequent update to 3.1.1 I lost my connection. I had to connect by USB and Pronterface and do the M997 S1 to update the Wifi Firmware. I thought that happens during the update process usually but it seems not. After that I was able to connect fine.

    I've taken bits and pieces from all of the various peoples firmware, thanks for those who shared. I had a bit of fun at first reading David's one since there 0,0 is bed center rather than front left. I have all of the fans and thermistors working and homing and tool changes are working, so I think things are in pretty good shape.

    Right now I've only swapped one of my V6 tool heads for a Hemera so I was just playing around since I wanted to have RRF3 running before commissioning fresh. However one thing I did notice is that if you have a mix of Hemera and V6 tools using their respective receivers you will have problems since when collecting the V6 tool the X-axis belt will hit the back of the Hemera toolplate.

    I'm switching to all Hemera anyway so it's a non-issue. If someone needed to run both I imagine you'd need to make a receiver adapter that pushes the V8 docking position forwards.
     
  18. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    450
    Likes Received:
    204
    See section "Extending the docks for the Bowden tools" at https://miscsolutions.wordpress.com...l-changer-to-duet-3-with-hemera-tools-part-2/ for how I handled this.
     
    Michael Pearson and Paul Arden like this.
  19. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    Those articles are great! I misread the section you mentioned when I first went through as I thought it was about extending them to make room for the toolboard, I didn’t read carefully enough.

    In any case, I’m replacing all tools with Hemera so it’s a non-issue for me now.
     
  20. Paul Arden

    Paul Arden Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    160
    Likes Received:
    52
    I think I am getting RRF3 under control now. I have just updated to physical endstops and have that all functioning however there is one issue.

    With the physical endstop configuration here, the Y axis must be at or very near the minimum in order for X to home successfully (since the X switch is mounted on the frame, not the cross bar. I was wondering if I could do something like this in my homex.g to get around this?

    Code:
    if move.axes[1].homed && move.axes[1].userPosition > -49 && move.axes[1].userPosition < -44
      ; Home x
      ..
    else
      abort "Cannot home X axis while Y axis is not near endstop or Y is not homed"
    
    Note sure if I can have numerical expressions in the if so I could calculate as an offset from the configured minimum instead but I guess the above would work (just means editing more files if I change the extent).

    My main goal here would be to prevent myself accidentally hitting the home X button in the web interface before the home Y button.
     

Share This Page