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,905
    Likes Received:
    3,593
    Current files are located here:

    RC8 Automatic Bed Leveling: # 926
    RC8 MESH Bed Leveling: #927

    RCBugFix Automatic Bed Leveling: #1153
    RCBugFix MESH Bed Leveling: #1152

    RCBugFix Uniform Bed Leveling (Experimental): #1116

    A new version of Marlin was released and I had a bunch of time on my hands waiting on a print so I went exploring within the new source code. All lines changed from Marlin's default settings are commented and contain the string: --BH.
     
    #1 WheresWaldo, Jun 11, 2015
    Last edited: May 1, 2017
  2. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    So here is where this stands. all the modified files are located in my fork of the GIT repository, it is located here:

    https://github.com/WheresWaldo/Marlin/tree/Release/Marlin/example_configurations/robo3d

    Done:
    1. Nearly all the new features that apply to Mendel style printers is enabled.
    2. The information @Ziggy supplied for displaying Babysteps is also implemented.
    3. FGSC is enabled and the encoder is reversed as it applies to most of the cheap Chinese clone smart controller boards.
    4. Had to shorten some strings in language.h to fit display screen.
    5. Every line I changed has the comment //ROBO-BH at the end of the line.
    Todo or Questions:
    1. The Progress Bar for SD printing is not enabled, some compile time errors that I need to investigate.
    2. I am not sure if the Babystep display for the Z-Axis takes into account the BABYSTEP_Z_MULTIPLICATOR from the Configuration_adv.h file so it may be displaying only half the actual value. I would love for someone with actual programming skills to check this for me.
    3. Only the English strings have been changed.

    There are a few things I am not sure about, it works, it displays proper information on the full graphics smart controller, printing from SD works as well as tethered to a PC. Not sure what else would be of value to Robo. Like I mentioned, not a programmer so I don't understand all the code.
     
    daniel871 likes this.
  3. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    Playing some more, I think the Progress Bar for SD Card Printing is only for the 4 line smart controller. There is already a progress bar on the larger full graphics panel. At this point I am not going to work on that anymore.

    There is an issue with Z offset, there is a define for adjustable Z offset that I believe interferes with the Robo Auto Level. I am going to see if disabling that feature helps.
     
    #3 WheresWaldo, Jun 12, 2015
    Last edited: Jun 12, 2015
  4. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    At this point, I would not recommend anyone use this code. I can't figure out how to get the Z Offset to work and it just seems to ignore the M565 command no matter where you put it in the g-code or by how much you apply. Tried the same file with the code at M565 Z-0.5, M565 Z-1.0 and M565 Z-1.5, they all start in the same spot touching the build plate and requiring around 200 babysteps to get if off the build plate and start extruding. Please note that this same file prints fine in Marlin 1.0.0.

    Since I am not qualified enough to figure out what it is doing, I am going to leave it up and look at it occasionally. Maybe I can learn something about C++ in the meantime.
     
    mark tomlinson likes this.
  5. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    I recall some talk in the Marlin forum about M565 not being generically implemented.
    Maybe diff that against the default Robo firmware and see if you can catch it?

    @Ziggy had some insight on that as well I think I recall.

    Still jolly good work so far with what you have dug up.
     
  6. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    I have switched to using M206 to write the Z offset, M500 to store it in EEPROM and also placing a default in configuration.h in #define Z_PROBE_OFFSET_FROM_EXTRUDER of -1.2 hoping that would likely be enough in the event of a crash or revert to defaults. But maybe I am not understanding it as well as I like. The first layer is jammed up against the build plate still.
     
  7. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    Decided to try and do some more work here and found out some interesting things about how Marlin works and what Z_PROBE_OFFSET_FROM_EXTRUDER does. Everyone knows that your 3D print head should not touch the bed, but that is how switch Z Axis probes work on the Robo, it keeps lowing the head until the carriage is lifted off the switches. There is a no man's land, a distance the head moves after it touches the bed and before it deactivates the switches, this distance is the Z_PROBE_OFFSET_FROM_EXTRUDER. Unfortunately for us the build plate is not 100% rigid, so there is a bit of flex before it triggers and that needs to be incorporated in the equation. Anyway, I took my highest point on the bed (my bed has been physically leveled and there is a 0.14 mm delta between the highest and lowest points) and moved the Z axis up 2 mm, then placed a piece of tissue paper under the hotend. Lowering the hotend 0.01 mm at a time, I came to a measurement where I could no longer move the paper, that was at 1.19 mm. So in Configuration.h (which is where this info belongs) on line #define Z_PROBE_OFFSET_FROM_EXTRUDER I changed the 0 to -1.19. The number is negative since the head would actually sit below the bed when the switches are triggered.

    Here is my problem. The Z_PROBE_OFFSET_FROM_EXTRUDER works perfect with G28 (home all axis). When that command is issued it moves left, then forward then over to the middle and finally down until the endstop is triggered. If you look at an LCD smart Controller it will show your Z axis at Z-001.1 (the display is truncated, the printer knows your at -1.19) if you subsequently issue a G1 Z0 command the head will raise by the amount of the offset and be barely touching the plate. You would think that would be perfect.

    Here is the issue, when you want to auto-level, that routine seems to throw away the offset and slams the head into the plate at the 9th location and sets that as Z0, so now you are off by the offset originally set. I just don't know enough about programming to understand this behavior. When you try to print it is slammed downward against the glass bed and if the first layer height is small It will just jam the extruder and not print at all.

    The final location should be X220 Y240 Z(0+Z_PROBE_OFFSET_FROM_EXTRUDER), in our case a negative value. At least this is the way that makes sense to me. If someone with more programming skills could look at this and tell me I am stupid and doing something obviously wrong, I would love to know what it is. As far as the rest of 1.0.2, all other features work fine, including the new display features and thermal runaway features.
     
    #7 WheresWaldo, Jun 13, 2015
    Last edited: Jun 14, 2015
  8. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    @Ziggy is more familiar, but hasn't been seen lately :)
    I will take a look later today and see if I can add any value.
    I have done my share of Arduino programming and have a basic familiarity with Marlin.
     
  9. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    Pulling your branch from 6 days ago.
     
  10. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    After it completes the bed leveling it should be sending out some coordinate maps:
    (basically dumping the bed leveling grid):

    // Print calibration results for plotting or manual frame
    SERIAL_PROTOCOL_F(bed_level[x][y], 2);


    Do you get that in the serial monitor (are you even running the serial monitor?) and what are the values?

    It might to be corrupting the grid values...

    (we can take this to PM if you want).
     
  11. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    Didn't know about the serial monitor. Will research, remember I am not a programmer. It would be wonderful if we could chat about this once you look at my fork. If there is a bug, I can post it in the Marlin GIT as an issue. I know that since they added all the Delta Auto-Level stuff there are a lot of people complaining about erratic behavior and loss of functionality. Until Auto-Level code is refactored it is also very hard to understand as well as maintain. I am hoping 1.1.x has this thought in mind and segments all the auto-level code, there would be a heck of a lot less #ifdef's.

    Sad to think this is so close. I have not had any other issues with any feature of the new code. If this could be figured out then I could suggest it to the Robo guys, there is a bunch of stuff any printer that wants to be plug-n-play could use.

    Aha, never paid attention in the Arduino IDE, serial monitor is right there, cool.:oops:
     
  12. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    Marlin is hard enough simply because of the way it twists and turns and having auto-level added in the way it was did not help.

    I think you are now, welcome to the dark side.

    Let me know if the values it is spiting out for the auto-level mapping seem sane or not.

    I am installing GIT and doing some setup so that I can do a proper sync of the snapshot you have and probably the Marlin HEAD as well (just to compare what you have changed).
     
    #12 mark tomlinson, Jun 14, 2015
    Last edited: Jun 14, 2015
  13. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    OK, I fired in a PULL request. You can let me know when I can clone it.

    EDIT: NM just cloned it instead
     
  14. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    I am now working with the Marlin developers to see if auto-level could be "fixed" in Marlin for the Robo. It is not just broken for the Robo but other printers also. 1.0.2 and above have a lot of neat features for unattended printing to help prevent you from burning down your Study/Den/Bedroom/Garage or wherever you keep your Robo. There is a new addition for a filament sensor that adjusts extrusion based on filament diameter and there is more stuff, plus a host of bug fixes. Since we would be using the latest code it might be easier to keep it updated. I hope this side project works out. As of this moment Auto-Level does not work properly but all other features appear to be functioning without any issues.
     
  15. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    It looks like the developers found some logic errors in the ABL routines as a result of trying to get the latest Marlin firmware running on the Robo R1. I will be testing on my machine as soon as they fix up the current development branch. If my testing is successful, it would be great if someone else with an R1 tests also, to validate my results.
     
  16. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    If you tell me when the fix is done, and what I should be looking for, I'll test it.
     
  17. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    Soon, they have checked in those changes (and appear to be in agreement at this stage over how it should behave).
     
  18. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    Just to keep everyone up to date. I was able to test a fix with 1.0.3 Development and I can say that auto-bed-leveling is working on the Robo. Of course they broke something else in the process. I have another issue submitted for that one. When this new issue is fixed I will package up everything for anyone that wants to test a newer version of Marlin.

    So I asked the developers specifically about release versions, as 1.0.3 is a development version and 1.0.2 is the release version. In the software business I used to be in, release versions are supposed to be bug free (or at least nothing that created data loss), not so for Marlin. When they feel it is relatively stable and they have done a finite number of fixes to the code, they release it, bugs and all (including show-stoppers). So 1.0.2 had a lot of stuff broken in it, but they wanted to increment the version number, so it was 'released'. All of this is to say, don't be afraid of 1.0.3 just because it is labeled a development version. It has more fixes and is likely more stable than their previous release. I am hoping that it won't be too long before they have patched up 1.0.3 enough for us to use.
     
  19. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    Most open source tends to be rather ad hoc about releases. Only the more mature ones have an actual process behind it :)
     
  20. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    Okay folks, It looks like things are looking up and I have a zip file that is ready to test. All the changes to the default configuration are documented with a comment that starts //--ROBO-BH. So if you want to see them just search for that string and it will be found on a line that either is something Robo changed or something that looked like a best practice suggestion from the forum. There are a few convenience tweaks, such as faster Auto-Bed-Level as well as a more accurate number for E-Steps. There is an extruder offset built in of 1.2 mm to avoid scraping along the build plate while homing, you will still need to set the actual zprobe_offset either in your startup gcode or from a terminal window. To set zprobe_offset you will need to use the M851 command as the M565 command appears to have been deprecated. EEPROM has been enabled for writing so you can save your settings and it will survive a reset or powering off. No additional hardware is currently enabled (mostly LCD screens). If you have a Full Graphics LCD Smart Controller, the display has been cleaned up quite a bit, it is a worthwhile feature in itself. All thermal runaway features have been enabled. All edits are solely in Configuration.h.

    All the necessary files are here to compile and run on your R1. Kickstarter Robo's and those first R1's will need to make the appropriate edits to Configuration.h before compiling and uploading.

    One more note, I am using this version as a daily driver, but I am not a developer nor am I supporting this version. Please use at your own risk. If there is something that doesn't work I will be happy to assist you in reporting it to the developers on GITHUB.

    The usual disclaimers apply.

    Since this forum does not allow uploading of .rar files, a .txt extension has been added. After you download it remove the .txt extention before attempting to unzip the file. One more thing, you have seen me complain about version numbers, this one will appear to have an odd version number but it actually has a meaning and helps me keep track of when I make changes to test things out.
     
Thread Status:
Not open for further replies.

Share This Page