1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

Marlin Firmware Upgrade 1.1.0 RC8 & RCBugFix (For R1 & R1+PLUS)

Discussion in 'Mods and Upgrades' started by WheresWaldo, Jun 11, 2015.

Thread Status:
Not open for further replies.
  1. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    @kapakai Ideally yes, but not 100% necessary, remember that the stepper motor is designed to move in full steps, and one full step will be 0.04 mm of rise, so those heights are sort of set in stone. but the RAMPS board implements something called microsteps, where they divide the electrical signal to the stepper into 16 different amounts. It is too hard with cheap hardware to make sure they are equal steps or precise steps and there is no feedback loop built into stepper motors to see if they are precisely in the correct spot. The microsteps give you finer grain control of the head position within the manufacturing limits of the parts provided. So essentially you can set pretty much any height you want, just be aware that there is no guarantee that 2 full steps + 8 mircosteps is really equal to 0.1 mm of movement, for all practical purposes it is. I tend to try to use full steps as those are reproducible and will allow the stepper to run cooler. But I am also using TR8*2 lead screws now which provides 0.01 mm rise per step.
     
    kapakai and mark tomlinson like this.
  2. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    Decided to try something borrowed from U.B.L. to validate the MESH that can be easily created, because I still have issues in certain spots on the bed, but I think that is because the switch stops and implementation of how the R1 is homed in the Z axis, is not the most repeatable method in practical terms. So I created this:
    Untitled-1.png
    It is just a simple grid, 0.25 mm high using 218 mm X 228 mm of the bed each line is 2 mm wide, which is pretty much the entire printable area of the bed. Since I use a 6 x 6 matrix with MESH the model is divided into sections that place the intersections where the probe points are. It should take less that 10 minutes to print. Sliced using 0.25 mm layer height will result in a single layer print.

    Now once you have leveled your bed and printed this model, you can measure all the intersections and see if your MESH creation was good or not. Any point can then be adjusted to correct for any anomalies using the G29 S3 Xn Yn Zn.nn to modify a single point in the grid. Here is how you would use this. You first need a report of the current grid which can be created in terminal mode of your slicer by issuing a G29 or G29 S0 command, note that X=1 Y=1 on your readout will be the top left corner of your grid. It might be easier to write these down on a piece of paper. With that recorded, let's say the 3rd row 2nd column point needs to move up 0.05 mm because it is too close to the bed, if your original value there was for example 2.1250 mm you would issue the command G29 S3 X3 Y2 Z2.175 to move it up the required amount (2.1250 + 0.05 = 2.1750). Now let's say that row 4 column 5 is too fat by the same 0.05 mm so you want to move it closer to the bed, the original value there was 2.2000 mm, you would enter the command G29 S3 X4 Y5 Z2.15 to adjust the required amount (2.2000 - 0.05 = 2.1500). Don't forget to save the newly adjusted mesh with an M500 when you are through. Once that is all done, you can basically forget about doing this again as long as the printer isn't jarred or parts replaced, as you will have a completely adjusted and verified MESH plane.

    I have attached the model I used for my 6 x 6 MESH.

    Note: Since I am in the process of doing this and have not completed it yet, I may have the math backwards, once it is verified I will edit this post.
     

    Attached Files:

    #1102 WheresWaldo, Apr 8, 2017
    Last edited: Apr 8, 2017
  3. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    Just another thought about the above procedure, in my personal R1 I disabled the line #define Z_SAFE_HOMING by commenting it out. This cause any G28 command to home X then home Y and stay at X0 Y0 to home Z instead of moving to the middle of the bed. I feel that homing Z in this case is more consistent than homing Z in the middle of the bed where is can flex the most.
     
    Robert55 likes this.
  4. Robert55

    Robert55 Member

    Joined:
    Apr 27, 2015
    Messages:
    94
    Likes Received:
    34
    Ah ha!! You got it to work, huh?? I was wondering. I like it in the corner because I want to do more multiple process prints with S3D. First few layers with the 0.8mm nozzle for background, then swap out to a 0.2mm for foreground stuff - lettering, etc. S3D slices it to home before starting a print, even if it starts at the 12th layer...

    Sent from my LGLS996 using Tapatalk
     
  5. Sean Carson

    Sean Carson Member

    Joined:
    Feb 4, 2016
    Messages:
    155
    Likes Received:
    22
    Supposedly, the z offset bug has been fixed in RCbugfix. Have you tried playing with it yet, whereswaldo?
     
  6. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    No, because they are messing around too much with the code, besides I need to pull apart my R1 since I have gotten it clogged. I am still using files from March 15th.
     
  7. Sean Carson

    Sean Carson Member

    Joined:
    Feb 4, 2016
    Messages:
    155
    Likes Received:
    22
    I'm getting some weird behavior I can't explain from Marlin. I'm posting it here because it might be a marlin bug, or it might be me overlooking something. If it belongs elsewhere, sorry, I'll move it.

    I set the printer up for mesh level. I leveled against my bed and some receipt paper. I autotuned PIDs and checked sensors, steppers, heaters, fans, and triggers, all happy.

    Then I try to home the hotend. This is where I am having trouble. I tell it to home XY in octoprint. It does this. I tell it to home Z. It does this. M114 tells me
    X:110.00 Y:118.00 Z:0.00 E:2.86 Count X:8800 Y:9440 Z:3200

    So lets raise and lower the hotend.
    ---raise---
    G91
    G1 Z10 F200
    G90
    M114
    Recv: X:110.00 Y:118.00 Z:10.00 E:2.86 Count X:8800 Y:9440 Z:9920
    ---lower---
    G91
    G1 Z-10 F200
    G90
    M114
    Recv: X:110.00 Y:118.00 Z:0.00 E:2.86 Count X:8800 Y:9440 Z:1920

    The head is now LOWER than when I homed it. Its at the real zero point now, not floating after leveling. At this point, it's 2:30 in the morning, so I have no idea what I'm actually doing.

    Let's try again. Home everything.
    M114
    Recv: X:110.00 Y:118.00 Z:0.00 E:2.86 Count X:8800 Y:9440 Z:3200
    G91
    G1 Z-0.1 F200
    G90
    M114
    Recv: X:110.00 Y:118.00 Z:-0.10 E:2.86 Count X:8800 Y:9440 Z:1840 <----WRONG! The nozzle lowered by far more then 0.1!
    G91
    G1 Z0.1 F200
    G90
    M114
    Recv: X:110.00 Y:118.00 Z:0.00 E:2.86 Count X:8800 Y:9440 Z:1920 <---WRONG! The nozzle is not back where it started.

    Maybe I sill have some off settings, even after reflashing and recalibrating. Lets see.
    M503
    Recv: echo:Steps per unit:
    Recv: echo: M92 X80.00 Y80.00 Z800.00 E419.00
    Recv: echo:Maximum feedrates (mm/s):
    Recv: echo: M203 X500.00 Y500.00 Z10.00 E25.00
    Recv: echo:Maximum Acceleration (mm/s2):
    Recv: echo: M201 X900 Y900 Z100 E10000
    Recv: echo:Accelerations: P=printing, R=retract and T=travel
    Recv: echo: M204 P600.00 R3000.00 T3000.00
    Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
    Recv: echo: M205 S0.00 T0.00 B20000 X15.00 Y15.00 Z0.40 E5.00
    Recv: echo:Home offset (mm)
    Recv: echo: M206 X0.00 Y0.00 Z0.00
    Recv: Mesh Bed Leveling:
    Recv: echo: M420 S1
    Recv: echo: G29 S3 X1 Y1 Z2.40000
    Recv: echo: G29 S3 X2 Y1 Z2.50000
    Recv: echo: G29 S3 X3 Y1 Z2.60000
    Recv: echo: G29 S3 X4 Y1 Z2.80000
    Recv: echo: G29 S3 X5 Y1 Z3.00000
    Recv: echo: G29 S3 X1 Y2 Z2.30000
    Recv: echo: G29 S3 X2 Y2 Z2.40000
    Recv: echo: G29 S3 X3 Y2 Z2.50000
    Recv: echo: G29 S3 X4 Y2 Z2.70000
    Recv: echo: G29 S3 X5 Y2 Z3.00000
    Recv: echo: G29 S3 X1 Y3 Z2.20000
    Recv: echo: G29 S3 X2 Y3 Z2.30000
    Recv: echo: G29 S3 X3 Y3 Z2.40000
    Recv: echo: G29 S3 X4 Y3 Z2.70000
    Recv: echo: G29 S3 X5 Y3 Z3.00000
    Recv: echo: G29 S3 X1 Y4 Z2.10000
    Recv: echo: G29 S3 X2 Y4 Z2.30000
    Recv: echo: G29 S3 X3 Y4 Z2.40000
    Recv: echo: G29 S3 X4 Y4 Z2.60000
    Recv: echo: G29 S3 X5 Y4 Z2.90000
    Recv: echo: G29 S3 X1 Y5 Z2.20000
    Recv: echo: G29 S3 X2 Y5 Z2.30000
    Recv: echo: G29 S3 X3 Y5 Z2.40000
    Recv: echo: G29 S3 X4 Y5 Z2.60000
    Recv: echo: G29 S3 X5 Y5 Z2.90000
    Recv: echo:Z2 Endstop adjustment (mm):
    Recv: echo: M666 Z0.00
    Recv: echo:Material heatup parameters:
    Recv: echo: M145 S0 H190 B55 F255
    Recv: M145 S1 H240 B110 F0
    Recv: echo:pID settings:
    Recv: echo: M301 P25.55 I2.39 D28.43
    Recv: echo: M304 P143.49 I28.07 D183.38
    Recv: echo:Filament settings: Disabled
    Recv: echo: M200 D1.75
    Recv: echo: M200 D0
    Recv: echo:Z-Probe Offset (mm):
    Recv: echo: M851 Z0.00

    Nothing weird there. No matter what I try, it prints above the buildtak. After some poking around, I was able to get it to print INTO the buildtak, ruining a sheet. Eventually, I got it close with I thin G29.2, I don't remember, but when I tried printing again, the went back to sky prints.

    Lets look at my starting script in S3D.
    G28
    G29
    G1 Z5 F5000 ; lift Z by 5mm so it doesn't rest on the BuildTak while heating.
    M190 S[bed0_temperature]
    M109 S[extruder0_temperature]

    Nothing weird there. There's nothing playing with offsets. The offset setting in another table is completely zeroed out too.

    EDIT: After M503, E should be 418.5, not 419.00. Still, thats not relevant to this problem.
    EDIT2: It seems I'm using the Feb 15th version, not the March 15th version. I'm not sure how I missed that. Was this an issue with the February version?
     
    #1107 Sean Carson, Apr 10, 2017
    Last edited: Apr 10, 2017
  8. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    No idea. I settled on March 15th since that was the latest version that still had MESH working, they really F'ed it up when trying to integrate U.B.L. and then changing all the variable names. My guess is they never heard of recursion testing. I won't look at it again until after April 15th.
     
    mark tomlinson likes this.
  9. Sean Carson

    Sean Carson Member

    Joined:
    Feb 4, 2016
    Messages:
    155
    Likes Received:
    22
    I tried the march code. No difference. It still prints in the air. Moving down is inconsistent. Strangely, if I use G0 Z0, it goes exactly where it needs to go. I added that to my gcode starting script and it didn't help.

    EDIT: I can't explain some of the odd behavior from before, but I found out why nothing is getting better. I read the Gcode in a text editor and found I still had a significant offset set in simplify3D. I swear I zeroed it out. Now it's digging into the bed. Oops
     
    #1109 Sean Carson, Apr 11, 2017
    Last edited: Apr 11, 2017
  10. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    @Sean Carson Offsets can always end up biting you in the ass. I remove all references to offset in my startup gcode. I don't like software doing anything that can be done with the Hardware/firmware combination. That way gcode=gcode=gcode no matter what printer I need to use it on. I just experienced this first hand last week. I had a model that S3D refused to slice correctly no matter what I did, @Geof was kind enough to slice it for me and send me the gcode. After a couple of failed prints I looked at his code and saw that he was doing a mechanical adjustment with software and had a line in there that explicitly changed the Z offset for every print. It ended up messing up my setup but I was able to print it after I removed the offending line from the gcode.

    When you look at things like gcode, they are supposed to be at a higher level independent of the hardware it is run on, but then we all sabotage ourselves by "fixing" our hardware inconsistencies with snippets of code that only work on our single printers.
     
    Geof, Sean Carson and Robert55 like this.
  11. Geof

    Geof Volunteer Moderator
    Staff Member

    Joined:
    Nov 9, 2015
    Messages:
    6,551
    Likes Received:
    2,258
    After removing the offsets that I've always used after @WheresWaldo let me know it gave him troubles, my start sequence is VERY smooth now. Much smoother than its ever been, crazy how something so routine can cause wierness
     
    Sean Carson likes this.
  12. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    I know that at times I have proposed doing things different than the "accepted" normal way of doing stuff. Take bed adhesion for example. I want my layer heights to be correct, which is a mechanical setting. Then I can adjust the flow of plastic or overlap or a combination of things to get he adhesion correct, that is a software thing. It makes for more accurate printing. Anyone who has read my past posts know that I feel we are at a point in the technology where we have very precise hardware, but precision and accuracy are not the same, I want both!

    @Sean Carson I experimented with the grid print some and I think I need to:
    1. Simplify the grid
    2. Figure out how Mr. Patel represented the grid so I can work off the printed model. I am not sure I got the math right in my test outlined above.
    3. The March 15th files do respect Z Offset using G29 S4 Zn.nnn
     
    Sean Carson likes this.
  13. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    So it is the 17th, taxes all done and here are the files for Marlin 1.1.0 RCBugFix as of April 16, 2017. I have separated them out into several compressed archive files. Just download the one you need and extract the appropriate files within the Marlin source sub-directory. You cannot use configuration files from previous Marlin releases or from previous Release Candidates. These archives contain the complete source modified as noted. This version and future versions of Marlin must be compiled on Arduino IDE 1.6.8 or newer.

    Basic steps required:
    1. Download one of the attached files appropriate for your hardware
      RCBF_MESH_R1_04-16 for Robo R1 with 8 mm Z Axis threaded rods
      RCBF_MESH_PLUS_04-16 for Robo R1+PLUS and R1's upgraded with the Z-Axis lead screw upgrade kit from Robo3D
      RCBF_MESH_TR82_04-16 for Robo R1's with upgraded Z Axis 3rd party TR8*2 lead screws
    2. Compile and upload to your Arduino 2540 board using the Arduino IDE. Compilation has been tested with Arduino IDE version 1.8.2 only.
    3. After successful upload, clear EEPROM memory by issuing the following two commands in terminal mode:
      M502
      M500
    4. Re-enter you Z axis offset, if needed, using G29 S4 Zn.nn, where n.nn is the amount of offset from the bed. M565 and M851 support are not supported in this version of Marlin.
    5. Make sure to run the PID auto tune routine for your printer for both hotend (E0) and bed (E-1). Edit Configuration.h with your specific values and recompile and upload to your printer.
    Common to all these files are:
    1. Set up for Hexagon hotend
    2. Full Graphics LCD enabled
    3. EEPROM memory enabled
    4. MESH Bed Leveling enabled w/25 probe points (5 x 5 grid)
    5. Major performance improvement for Graphical LCDs
    6. MESH adjustment heights configured to prevent fractional micro-steps
    New - You supposedly can use Baby-stepping to adjust M851, but it is not enabled in this version.

    New - There is a new function for status RGB LEDs it is located in Configuration.h lines 1535 - 1549 if you care to enable it. If you do let us know how it works (I'm speaking directly at you @danzca6 ;))

    Please note that I am not one of the Marlin developers. If you have an issue with this release post here first. If it is determined that it is not a configuration issue, then you may be directed to post the issue on Marlin's GITHUB. I cannot guarantee success using beta firmware, I can vouch for error free compiling with these included files. If there are issues with the configuration let me know and we can work on them together. Original post (#1) edited to provide a link to these current RCBugFix files.
     

    Attached Files:

    danzca6 and mark tomlinson like this.
  14. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    April 17th Daffy Duck debuts in 1937, the Ford Mustang is shown at the World's Fair in 1964 and here are the files for Marlin 1.1.0 RCBugFix as of April 16, 2017. I have separated them out into several compressed archive files. Just download the one you need and extract the appropriate files within the Marlin source sub-directory. You cannot use configuration files from previous Marlin releases or from previous Release Candidates. These archives contain the complete source modified as noted. This version and future versions of Marlin must be compiled on Arduino IDE 1.6.8 or newer.

    Basic steps required:
    1. Download one of the attached files appropriate for your hardware
      RCBF_ABL_R1_04-16 for Robo R1 with 8 mm Z Axis threaded rods
      RCBF_ABL_PLUS_04-16 for Robo R1+PLUS and R1's upgraded with the Z-Axis lead screw upgrade kit from Robo3D
      RCBF_ABL_TR82_04-16 for Robo R1's with upgraded Z Axis 3rd party TR8*2 lead screws
    2. Compile and upload to your Arduino 2540 board using the Arduino IDE. Compilation has been tested with Arduino IDE version 1.8.2 only.
    3. After successful upload, clear EEPROM memory by issuing the following two commands in terminal mode:
      M502
      M500
    4. Re-enter you Z axis offset using M851 as a positive number. M565 is no longer supported in this version
    5. Make sure to run the PID auto tune routine for your printer for both hotend (E0) and bed (E-1). Edit Configuration.h with your specific values and recompile and upload to your printer.

    Common to all these files are:
    1. Set up for Hexagon hotend
    2. Full Graphics LCD enabled
    3. EEPROM memory enabled
    4. Automatic Bed Leveling enabled w/16 probe points (4 x 4 grid)
    5. BILINEAR bed leveling enabled as default
    6. Major performance improvement for Graphical LCDs
    7. Some other stuff
    New - Baby-stepping can be used to set the Z Offset (enabled)

    New - New routine to allow RGB LED to display printer status (not enabled). See section of Configuration.h just beyond line 1535.

    Please note that I am not one of the Marlin developers. If you have an issue with this release post here first. If it is determined that it is not a configuration issue, then you may be directed to post the issue on Marlin's GITHUB. I cannot guarantee success using beta firmware, I can vouch for error free compiling with these included files. If there are issues with the configuration let me know and we can work on them together. Original post (#1) edited to provide a link to these current RCBugFix files.
     

    Attached Files:

    #1114 WheresWaldo, Apr 17, 2017
    Last edited: Apr 17, 2017
  15. Sean Carson

    Sean Carson Member

    Joined:
    Feb 4, 2016
    Messages:
    155
    Likes Received:
    22
    What do you mean by automatic 16-point probing? Is this UBL? Does that mean I should upgrade or stay in march 15ths snapshot? Will I ever find love? Does my cat control my dreams? ANSWER ME, WALDO!
     
  16. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    Proof of Concept

    For the Bold and Daring! here is a set of files pre-configured for the R1+PLUS that uses the new Uniform Bed Leveling (U.B.L.) routine. All the same features that exist in the ABL files are enabled here. Compilation was tested with the Arduino IDE v 1.8.2 only. Firmware was not tested but it does compile without issue.

    I am not going to test this myself.
     

    Attached Files:

    #1116 WheresWaldo, Apr 17, 2017
    Last edited: Apr 17, 2017
    Robert55 and Sean Carson like this.
  17. Sean Carson

    Sean Carson Member

    Joined:
    Feb 4, 2016
    Messages:
    155
    Likes Received:
    22
    What about my cat? I really think she caused the dream about the post-apocalyptic hellscape, but can't figure out why.
     
    Robert55 likes this.
  18. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,795
    Likes Received:
    3,509
    Sean Carson likes this.
  19. Rat_Patrol

    Rat_Patrol Member

    Joined:
    Dec 14, 2016
    Messages:
    178
    Likes Received:
    24
    Please walk me through getting this setup into my R1+. Downloading 1.8.2 IDE now, already have the appropriate .rar file saved.

    I'm still VERY unfamiliar with arduino and playing with the firmware

    Thanks!
     
  20. Rat_Patrol

    Rat_Patrol Member

    Joined:
    Dec 14, 2016
    Messages:
    178
    Likes Received:
    24
    What has me confused at the very moment is : "extract the appropriate files within the Marlin source sub-directory"
     
Thread Status:
Not open for further replies.

Share This Page