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

Robo 3D R1 Plus ABL Firmware (RC8 and up)

Discussion in 'Mods and Upgrades' started by Aaron Lunger, Dec 23, 2018.

  1. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    So, I've been having this really strange issue.....

    I recently upgraded the firmware, and just got it working well (or so I thought). The prints were great again, and I was doing well. (Side note : I did this for the filament sensor upgrade, but the housing didn't work well so I disabled the filament sensor in the firmware, disconnected it at the module as well)

    However, now I'm running into this problem where the firmware locks up, or, as best as I can tell, slows down to a crawl.

    Now, this is the firmware on the robo. The COM port on the computer is functioning just fine, I checked it with my oscilloscope and verified the data it was sending and the baud rate it was sending at. It was NOT getting a response from the printer either.

    The only reason I know the robo slowed down is because I could force (I'm using simplify 3D) the computer to send the next line of data, and it would, and after 20 to 30 seconds, it might move 1 or 2 times, but then just locks up completely.

    Now, prior to this print, I did about a half dozen prints without ANY issues at all.

    Any clue at all what could possibly be causing this?

    I've tried all the RC8 and up firmares, except for the latest 1.1.9 I believe it is that was posted.

    I also prefer using the ABL (for now anyway), mainly because I have things to print in a timely manner right now....
     
  2. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    Probably not the firmware (I can't rule it out, but probably not that).
    If you want to rule it out reload the stock firmware as a test and see if the COM goes back to normal.
    Assuming it doesn't then the best bet is to try another Arduino (Arduino Mega 2560). That is the only one involved in the communications side.

    While rogue firmware could hang things up/slow things down I can't say that I have ever seen Marlin do that.
    It could even be a physical issue with the USB port on the Arduino (I have seen that before).
     
  3. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    I would normally agree, however, I have loaded the original robo firmware. It printed for days with no issues (other than it didn't work as well as the custom). No disconnects, no slowdowns, no issues.

    I replaced the Arduino with a brand new mega 256 last week because of this. Replaced the USB cable as well. Still happened (with custom firmware, robo firmware worked fine).

    I can't really seem to find anything else that it could be.

    I should probably mention I have the smart graphic lov as well. But no other mods. Standard R1 Plus with that LCD.
     
  4. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    LCD wouldn't matter.
    So I'd agree, something is wrong with that firmware :)
    If you don't need to be on that RC label, step back to the last actual release (not release candidate) and see if that sorts it.
    If it does it may be time to dig through the Marlin BugDB and see if there is something logged.
    If not, log one...
     
  5. Bradf80

    Bradf80 New Member

    Joined:
    Mar 24, 2015
    Messages:
    24
    Likes Received:
    7
    If you used 1.1.9 which is the release I worked on, by default it has the reprapdiscount smart controller enabled and the xxl full graphic disabled.

    Did you make sure you edited the firmware to your screen?
     
  6. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    I did not use the 1.1.9 firmware yet. I need to print things for an upcoming event and I really don't want to drastically switch how it functions (hence using the ABL codes).

    But yes, I always check the main things I like (ensure the correct LCD is defined, as well as setting up a 5x5 ABL grid instead of the default 3x3, or just making sure it's set to 5x5).

    So here's the real problem....

    Going back to the RoboR1PlusV2 code, I can't seem to change what the offset is for the Z height. I change it, but it always goes to the same place after bed leveling. This is an issue because it isn't level at all, its basically right on the bed, spot on, so it can't lay down a first layer.

    Using the RCBF_ABL_PLUS_12-01 (http://community.robo3d.com/index.p...bugfix-for-r1-r1-plus.5806/page-45#post-97535 ), I got good results initially, but eventually I would get random drops or slow-downs/halts, as explained above.

    Using the RCBF_ABL_PLUS (http://community.robo3d.com/index.p...bugfix-for-r1-r1-plus.5806/page-47#post-97888 ), I got good results initially, but eventually I would get random drops or slow-downs/halts, as explained above.

    Using the RCBF_ABL_PLUS_05-01 ( http://community.robo3d.com/index.p...ugfix-for-r1-r1-plus.5806/page-58#post-106709 ), I again got good results initially, but eventually I would get random drops or slow-downs/halts, as explained above.

    Side note 1 : Each time I install firmware, I ensure that I do a M502, followed by an M500 via the command line in Simplify3D, and it always responds with the correct "Loaded defaults" and "Saved" (or whatever the response is exactly....you get the idea). I also use the corresponding Z-offset setting within my startup script in Simplify3D (M565 Z-x.x for R1PlusV2, and M851 Zx.x for all others).

    Side note : I have tried all 3 of the above Marlin versions, along with the RoboR1PlusV2 code on both my OLD Robo Atmega256, as well as a brand new unused, freshly install Atmega256. Both program fine, and seem to run fine with the R1PlusV2 code, but I'm unable to adjust the Z height properly to get it to not be in the bed so much.

    I just reinstalled the original firmware. I'm running a long print now to see how this goes. But again, the Z height setting is still an issue. It's almost as if it's completely ignoring any setting that is input, to be honest. (ie the M565 command is useless)

    I've also tried various USB cables, some brand new ones, some older ones, even bought a brand new one right from the store.

    I'm running the latest version of Simplify3D (4.1 at this point I believe?). I've been using it with no issues prior to this.
    Prior to all of this happening (when I tried to install the filament run out sensor), I was running RoboR1PlusV2 without issue.

    I'm really just getting to the point that I hate my Robo because it just doesn't work. Which is sad, because I have loved this thing for the past 2+ years now and haven't had any incredibly bad issues like this previously.
     
  7. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    What does your startup GCode block look like when using that? Just curious as there are some constraints around how you use it.
    May not be the issue, but let's have a look.

    The 1.0.x firmware works as advertised on all of my R1 style machines (3) so I can attest to it not being a code issue :) Z offsets (M565) do indeed make a difference. So you may have something minor awry. I don't use the newer 1.1.x firmware because I never needed anything more than basic ABL (plus manual leveling of the frame and bed which we do anyway).
     
  8. Bradf80

    Bradf80 New Member

    Joined:
    Mar 24, 2015
    Messages:
    24
    Likes Received:
    7
    Do you print via USB or SD? I have noticed that if I print via SD while USB is plugged in, sometimes the printer will wig out and have some weird slowdown issue where it moves, but moves super slow. Unplugging the USB resolves this issue.
     
  9. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    Well, all mine have a Raspberry Pi with OctoPrint in front of them so ... technically all of them print via USB.
    I upload the STL to the OctoPrint web interface. Even our non-Robo printers all use this approach (except for the DLP -- that we use nanoDLP for)
     
  10. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    I have used all of the various printing methods on them at one point or another. They all have LCDs (they are all different from each other in which one they use) and I have printed that way with the version 1.0 firmware as well as from an attached PC.

    Given your symptoms (which related to USB connection) I would suspect the Arduino Mega itself.
    I'd try a swap on that (which at least is easier than a RAMPS swap since there are no wires to land on it other than the USB cable)
     
    #10 mark tomlinson, Dec 24, 2018
    Last edited: Dec 24, 2018
  11. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    I took the stock code from here : http://community.robo3d.com/index.php?threads/pei-sheets-precut-with-3m.20029/
    G28 ; home all axes

    G1 Z5 F5000 ; lift Z by 5mm

    M565 Z-.90; set the offset for autolevel to your numbers

    G29; Autolevel Dance

    M140 S[bed0_temperature]

    M190 S[bed0_temperature]

    M104 S[extruder0_temperature]

    M109 S[extruder0_temperature]

    Modified it slightly (mainly just changing the Z offset, whether it be M565 for old firmware, or M851 for newer firmware), and it's been working well.
    This is because I do have a PEI sheet installed and I don't want to melt it when auto-leveling.
     
  12. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    I do not use the SD card at all, and do not have one installed. I prefer to print directly from a USB computer, although I have been considering adding in a RaspPi running the C2/R2 firmware as a controller instead of a PC.....but that's a project for another time.
     
  13. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    I agree. However, I have already swapped to a brand new one, that was never used prior to this installation.

    I've been printing for 2 days now, almost constantly, with the new Mega using the RoboV2 code, without any issues other than the Z-offset not functioning as it should.

    I've still got another Mega I could use, that is rather old (~4 years) that I used for some arduino development work, but I'm still not convinced that a 3rd Mega will make a difference.

    Logically speaking, my symptoms just don't make sense. The PC/Simplify3D don't seem to be the problem, not when I can print for days with the RoboV2 code. But for whatever reason, the newer codes seem to have issues that I've only been encountering. Which would point to a hardware issue.....
    But if that was the case, why would the RoboV2 code work fine?

    This is my problem. I'm just not seeing where the issue is.
     
  14. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    Clear the flash EPROM (the EEPROM) and reload it from the base firmware. In a GCode terminal:


    M502;
    M500;

    See if that helps. If you do the M565 first (with the offset you want specified) it may store that too
     
  15. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    Directly after installing any firmware, the first things I do are:
    M502;
    M<Zoffset command, so either M565 or M851 depending on firmware version> Z<whatever offset>;
    M500;

    I then also verify via the LCD that the Z offset was stored.

    I do this because I'm well aware of how the saved settings can wreck havoc from version to version of the firmware (I dealt with that before, so it's part of my routine).
     
    mark tomlinson likes this.
  16. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    Cool. If that doesn't work then there is something corrupt with the Flash EPROM and that is on the Arduino too.
    You should be able to verify the setting is stored with
    M503

    That will at least confirm that the push into the EEPROM stuck.
     
  17. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    SENT: M503
    READ: echo:Steps per unit:
    Steps per unit:
    READ: echo: M92 X80.00 Y80.00 Z800.00 E723.38
    M92 X80.00 Y80.00 Z800.00 E723.38
    READ: echo:Maximum feedrates (mm/s):
    Maximum feedrates (mm/s):
    READ: echo: M203 X500.00 Y500.00 Z5.00 E25.00
    M203 X500.00 Y500.00 Z5.00 E25.00
    READ: echo:Maximum Acceleration (mm/s2):
    Maximum Acceleration (mm/s2):
    READ: echo: M201 X9000 Y9000 Z100 E10000
    M201 X9000 Y9000 Z100 E10000
    READ: echo:Acceleration: S=acceleration, T=retract acceleration
    Acceleration: S=acceleration, T=retract acceleration
    READ: echo: M204 S1300.00 T3000.00
    M204 S1300.00 T3000.00
    READ: 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)
    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)
    READ: echo: M205 S0.00 T0.00 B20000 X17.00 Z0.40 E5.00
    M205 S0.00 T0.00 B20000 X17.00 Z0.40 E5.00
    READ: echo:Home offset (mm):
    Home offset (mm):
    READ: echo: M206 X0.00 Y0.00 Z0.00
    M206 X0.00 Y0.00 Z0.00
    READ: echo:pID settings:
    PID settings:
    READ: echo: M301 P22.20 I1.08 D114.00
    M301 P22.20 I1.08 D114.00
     
  18. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    Yep -- looks like the M565 is not storing.
    I can't say if it should or not I just always have it in the startup GCode block regardless.
    That is more of a Marlin question.
    Looks like only the global home offsets (not the autoleveling Z offset) is stored:

    http://marlinfw.org/docs/gcode/M206.html

    So make sure you have the M565 specified in the startup script and you probably will see it work.
     
  19. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,671
    Likes Received:
    7,316
    CAVEAT
    I am no longer a contributor to the Marlin dev effort (things got too "political" for me to stay involved quite a while back) so what I know is coming from the wiki and if you want official comments go to their mailing list :)
     
  20. Aaron Lunger

    Aaron Lunger New Member

    Joined:
    Dec 16, 2016
    Messages:
    27
    Likes Received:
    2
    M565 is specified in my startup script (see above posts about it).
    The problem I have is that even if I change it, the printer doesn't seem to care about it. It doesn't appear to have any effect on the actual print anymore. I'll have to try M206 and see if I can work with that. It still doesn't change all the issues I've been seeing as of late.

    For what it's worth, I took the time to test all 3 Arduino Mega 2560's.
    None will hold the Z offset and include it in the offsets shown with the M503 command.

    That tells me one of 2 things....
    1. The Z Offset isn't included with an M503 command
    2. The Z offset (M565) in the original Robo V2 firmware doesn't work and it's useless to use it.

    As far as the newer firmwares, all I can really tell from them is that there is something broken with them causing the Arduino to freeze and not function properly.

    For what it's worth, 2+ days printing almost non-stop with the RoboV2 firmware on this 'new' Mega2560. If it was an issue with the hardware (ie slowing down, etc...), I would be seeing it by now.

    I'm going to keep trying things once I have more time, but really, something just isn't making sense here in regards to everything.

    I want to believe this is a hardware issue, but that just doesn't appear to be the case.
     

Share This Page