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

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    To clarify, does the reprapdiscount XXL LCD screen still work or just the full graphics one?
     
  2. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    As far as I know everything works, you will have to enable it in Configuration.h, I can only test with the Full Graphics since that's the only LCD I have.The defines for LCDs haven't changed from the original firmware version, so it will be located somewhere near the bottom of Configuration.h.
     
  3. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    As things change in the main code branch that affect the Robo (Mendel style printer) I will update the .zip. If there are changes necessary to Configuration.h I will just include that single file.

    So far I have been using this version all weekend and not found anything that has prevented printing. and I have had the Thermal Runaway trigger, when I was mucking with the thermistor. So I know that feature works as described. Unfortunately the developers are very bad at documenting what has changed so there isn't a changelog file for this firmware. I do know that they added hooks for a filament sensor (to measure the amount of filament drawn into the extruder), as well as thermal runaway (in case the thermistor fails or falls out) and filament runout sensor (that will tell ramps if the filament has run out).
     
  4. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    After my stepper controllers/drivers come in I'll be able to actually test it, but for now I've just got it uploaded to the robo while awaiting those parts.
     
  5. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    I'm getting this error when trying to open the extracted firmware in Arduino (marlin.h)

    Capture.PNG

    Is there something specific I should be doing that is different from modifying the regular Robo firmware? I updated Arduino to the latest release and got the same error.
     
  6. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    Filename and folder name must match exactly. I believe the .ino file is simply named Marlin, so it must go in a folder or sub-folder called Marlin.
     
  7. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    21,296
    Likes Received:
    7,024
    Open the INO file in the Arduino UI. Not the .H or . C files. The INO file will tell teh IDE to load those for you.
     
  8. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    There are a couple of new commits to solidify the function of zprobe_offset and to make sure it is used correctly. Inside this .zip file (renamed by adding .txt file extension for uploading here) are four files that have been updated with the current code, along with those four files are the two configuration files needed for the RoboR1. To implement this update, just remove the .txt extension and you are left with a .zip file. Open the .zip archive and copy all six files into the location you currently have the test version of the Robo firmware. Recompile and upload to your Arduino board with the Arduino IDE.

    As a point of reference, I have been using this code for over a week and had no printer/firmware related issues. Just to clarify what I am testing this on: RoboR1 with April 2015 manufacture date, RepRapDiscount Full Graphics Controller Chinese clone board, E3Dv6 hotend, and now just added a Raspberry Pi 2 running Octopi. Everything appears normal, but I am waiting for some debug code to allow the developer to verify the remediation of this bug. I have tested printing with Cura, Slic3r, Repetier-Host, as well as direct from SD card with and without Octopi control.
     
    #28 WheresWaldo, Jul 7, 2015
    Last edited: Jul 7, 2015
    daniel871 likes this.
  9. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    Is the control knob on the LCD supposed to be reversed on this firmware in terms of which direction to spin for increments?

    The old Robo firmware had you turning clockwise to increase values, counterclockwise to decrease values (or to the right to go down the menu, left to go up). This firmware has that reversed.

    I've got some other issues going on so I've gone back to the original firmware to make sure there aren't other things wrong first (stepper drivers acting weird, etc.), but that is the most immediate difference I noticed while fiddling with your latest compiled version.
     
  10. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    That is the default behavior of Marlin. Don't know why they have the encoder reversed, but it is easy to fix. The difference is in pins_RAMPS_13.h lines 165 and 166 must be swapped. The Marlin default is #define BTN_EN1 31 and #define BTN_EN2 33, for many Chinese Smart controller boards this must be reversed. I have included a modified pins_RAMPS_13.h here, or you can make the changes yourself.

    I would also like to know what your other issues are so we can determine if they are related to firmware. I have been running this version since the day they committed the latest patch to ABL and I am not having print related issues.

    One thing to note about Z Axis. If you want to have accurate prints as well as the proper height display on your LCD screen Marlin now requires that you leave the stepper enabled. Turning it off was used by the kickstarter Robo's to do all sorts of things to level the bed print to print. It was a workaround and should not be considered a "best practice". So in this firmware all three axes are active all the time. The current Robo official Auto-Level firmware should include this, but I fear it has been overlooked. In this firmware that option is located in Configuration.h line 365. which is #define DISABLE_Z false, in the Robo firmware (line 307) it is set to true, but should be changed to false if you have a current R1.
     
    #30 WheresWaldo, Jul 8, 2015
    Last edited: Jul 8, 2015
  11. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    The autolevel is having the 1st layer basically scrubbing the glass when it should be .45mm off the bed (1.0mm volcano nozzle).

    I've never had to adjust the offset before, should it be more negative or less negative on the offset for the M865?
     
  12. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    Are you still using M565 somewhere in your startup gcode? Whether or not you put it there, it is only there to set the offset. Without any offset you should never have been able to print anything, since the first layer would always have the nozzle below the level of the bed. In this post, #20, I specifically mention that M565 doesn't work with the new version of Marlin. zprobe_offset is now set with M851. So if it is scraping then you likely didn't change the M565 commands for the M851 commands. Also I am not a big fan of using M851 in startup gcode, and apparently neither are the developers, they mention that it should be in memory. At a terminal window, if you say yours should be -0.45 mm, issue the command M851 Z-0.45 then issue the command M500 to store that setting in EEPROM. Now until you decide to change it, you never have to issue that command again. It will be stored in a spot that will survive board resets and power cycles. It does not survive rewriting the firmware.
     
    #32 WheresWaldo, Jul 9, 2015
    Last edited: Jul 9, 2015
  13. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    I had changed the M565 to the M851 in my startup code (sorry about the wrong code in the earlier post, was phone-posting).

    Here is my starting G-code

    Code:
    G28 ; home all axes
    
    G1 Z5 F5000 ; lift Z by 5mm
    
    M851 Z-1 ; set the offset for auto-leveling mechanism
    
    G29 ; run auto-level
    
    ; This set of code is so that it autolevels before heating so that the BuildTek surface is not damaged
    
    G1 Z5 F5000 ; lift Z by 5mm so it doesnt rest on the BuildTek while heating.
    
    M140 S[bed0_temperature] ; Set Bed Temperature
    
    M190 S[bed0_temperature] ; Wait for Bed Temperature
    
    M104 S[extruder0_temperature] T0 ; set extruder temperature .
    
    M109 S[extruder0_temperature] T0 ; wait for extruder temp
    
    G92 E0 ;reset extruder to zero
    
    G1 E3 F300 ;prime extruder with 3mm of filament
    
    G92 E0 ;reset extruder to zero again just because


    How about eliminating bed leveling from the startup code and using the auto home and level bed commands in the LCD menu before running programs (programs would still home and raise up off the bed for heating cycles)? Would that work?
     
    #33 daniel871, Jul 10, 2015
    Last edited: Jul 10, 2015
  14. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    The bed leveling isn't the problem, its the offset that is. My startup gcode is a lot simpler than yours. I have the G28 followed by G29 with nothing between them, especially since G29 already lifts the nozzle before it starts there is no reason to lift it higher.
    Code:
    M107  ;Turn fans off
    M82  ;Set extruder to absolute mode
    G21  ;Set units to millimeters
    G28  ;Home all axis
    G29  ;Run auto-level routine
    G90  ;Set absolute coordinates
    G1 Z10  ;Make sure Z is off bed
    M117 Preheat.  ;Put preheat message on LCD screen
    M109 S[extruder0_temperature]
    M190 S[bed0_temperature]  ;Wait for heating
    G92 E0  ;Zero the extruded length
    M117 Printing.  ;Put printing message on LCD screen
    You will notice that there is no code at all for setting offset. I have one set, just not in my gcode startup. So maybe if I explain what I did you might be able to solve your issue. The first thing I did was to make sure that the extruder nozzle and the bed where as parallel as possible. I did this with a dial indicator and small discs made from shelf contact paper and a hole punch. With the adhesive back the contact paper stays in place on top of the magnets, I use as many of the little discs as needed to get the bed as level as possible around the four corners of the heated area (not the entire glass plate). Once leveled I measured just how far below the top of the glass plate the nozzle has to travel to get any of the limit switches to trigger. In my case is was -1.18, This was done at the Z-Axis home location as the glass plate flexes more there than anywhere else. This number was added to Configuration.h in the line that reads #define Z_PROBE_OFFSET_FROM_EXTRUDER -1.2, I did fudge the number a bit to make it 1.2 to assure that when G28 homing is done the nozzle would end up just above the glass plate if you were to issue a G1 Z0.

    Now that we know the home position is correct, we can work on the zprobe_offset (M851). One thing I found is that with this setup the zprobe_offset is not the same as the one I was using with the old M565 command. I started this process with a model of a 1 cm square that would slice to two layers only. Much faster printing this way and not wasting a lot of time and filament. I started with these commands in a terminal windows:
    Code:
    M851 Z-1
    M500
    Once printed I could first see if it stuck to the bed, then I could measure the height to see how close it was, If I was over layer-height x 2 then I knew it was off the bed. So I would do it again, same square but just before printing I would issue a M851 Z-.8 followed by an M500. Still too high and I would do it again, moving .2 each successive try. Once I was too squished I would try the in-between number. Then you can fine tune to the hundredth. By doing it this way I always had the M851 set and if I powered off or lost connection and had to reset, it was always there, verified by issuing a M851 command and noting the response.

    Of course if you are extruding extreme amounts of plastic, such as with a volcano, maybe the offset needs to be higher. Logic would tell you that more positive is higher off the plate, but in this case more negative is higher off the plate. What you are telling Marlin is that I want Z0 at this specific location and my Z axis minimum endstop triggers -n.nn below that point, that is the purpose of zprobe_offset (M851). Whatever that -n.nn number, this is the number you put in M851.
     
    #34 WheresWaldo, Jul 10, 2015
    Last edited: Jul 10, 2015
  15. jbigler1986

    jbigler1986 Active Member

    Joined:
    Feb 13, 2015
    Messages:
    534
    Likes Received:
    128
    I don't even use the M565 anymore. It was pissing me off. So I commented out M565 and I added
    G1 Z0.7
    G92 Z0
    to the end of my gcode. M565 offsets were not actually changing when I was changing the number. So that's when I went this route. No issues since.
     
    mark tomlinson and daniel871 like this.
  16. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    What does the rest of your starting G-code look like, jb?
     
  17. jbigler1986

    jbigler1986 Active Member

    Joined:
    Feb 13, 2015
    Messages:
    534
    Likes Received:
    128
    I will have to look when I get home from work and post it.
     
  18. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    Please read my entire post now that it has been completely edited. #34

    @jbigler1986, that really sounds like you were having other issues, M565 worked in the original ROBO firmware and M851 works in this one.

    Everyone, please note that you cannot arbitrarily take all the default numbers, even though these printers are precise machines there is no guarantee of repeatable accuracy without testing and using your own adjustments. If you only accept the default settings you will precisely have the same issues for each print. The settings in the firmware are just supposed to be sane default settings so you don't destroy your printer right out of the box. It is still up to you to make the necessary adjustments to get your acceptable level of accuracy!
     
    #38 WheresWaldo, Jul 10, 2015
    Last edited: Jul 10, 2015
  19. jbigler1986

    jbigler1986 Active Member

    Joined:
    Feb 13, 2015
    Messages:
    534
    Likes Received:
    128
    Oh trust me. I tried several different things and still would not work. I have edited several things and have modified my printer a lot. So it's not like I have no clue what I'm doing. It wouldn't work for a few days then magically it would start to work again. That's why i just avoided it because it was being a pain in the ass. Now every single adjust I need to make for the offset for whatever reason it actual accepts the change.
     
    WheresWaldo likes this.
  20. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,811
    Likes Received:
    3,536
    Yeah, I am pretty sure that your Robo is so far away from what you pulled out of the box that your setup is Robo in name only! :)
     
Thread Status:
Not open for further replies.

Share This Page