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

R2 - It arrived!

Discussion in 'Show and Tell' started by Kilrah, Jun 28, 2017.

  1. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    Box MUCH bigger than I expected. Printer somewhat so too, that's a hefty bit of kit!

    Like many it got a bit banged up during transport. The scratched door is pretty much a given, it seems they didn't learn from early feedback to fix later shipments.
    The tie-wraps and tape that were supposed to hold the door closed fell off and were loose in the box, which allowed the door to open a bit and the contents to move, dislodging the print bed. That wrecked 2 of the pogo pins.

    20170628_105243.jpg

    20170628_123409.jpg

    20170628_111207.jpg

    Fortunately I could find enough of the bits in the printer itself and the packaging to rebuild at least the thermistor one without which nothing will run. Missing the inner part of the 2nd, but that's not too bad as one power contact does the job well enough until I can get a replacement board.
    Next thing is my extruder cooling fan has borked bearings - whiny/vibrating all the time (and it always runs). Will see if it breaks in.

    20170628_111144.jpg

    20170628_111340.jpg

    Now to the good stuff - All the "most important" stuff seems in perfect working order, rods are straight and aligned, homing switches OK, no other mechanical issues. I started by imaging the SD card, and actually put it away in the parts box and wrote the image to a faster one. Updated the software+octoprint plugins, ran a Z offset calib, noticed bed level was awful so started a bed leveling only to see that I didn't have enough adjustment range on the screws, so I screwed them half in and redid a Z offset calib, then I got enough once I repeated the leveling. One more Z calib after leveling for confirmation and all done.

    Printed the supplied "test print" gcode file with the blue PLA and it came out great (except I don't like rafts :p).

    20170628_145323.jpg

    20170628_145349.jpg

    So now onto more stuff, and currently running a 5h PETG print. This thing can be pretty fast, I've sliced with the standard 50mm/s but then increased in steps up to 180% during the print without much visible difference, settled up for 160% after a while "just in case".

    Quirks so far in no particular order:
    - Temperature management is pretty awful - it seems by default the startup GCode in Octoprint is what defines the temps and nothing can override them - so your slicer settings do nothing, and the manual adjustments are locked. I commented out the temp settings in the startup Gcode, but then nothing heats things up for the priming stretch if I don't do it manually before starting a print. Also the supplied Cura profile does not seem to set things to wait for temps to be reached before starting to print, so again without manual preheating you'll just print nothing at all since the extruder will be cold.
    - Cosmetic, but the LCD is a bit low in the frame opening and cuts the bottom of the text on the settings screens
    - Wi-Fi network list sems not to always update without doing a reboot if disconnected during use (flaky router...). It falls back to hotspot mode, but the password for that isn't documented that I can find.
    - Robo's main "Support" link is down, "trial ended" for the desk software it seems. http://help.robo3d.com/
    - Bed temp seems to be way out of cal - when you set it to 100°C it measures about 75°C with an IR thermometer. It isn't able to heat much more than that even when trying, as set of 103 just works, I think 105 would barely ever be reached.
    - Slowly travelling over the whole Z range very frequently is really boring - Now I know why I like Z0 sensors. Hint, there's something that could be done with optical sensors...
    - Webcam needs manual enabling on each power-up, haven't found how to automated that (not tried much either).

    Apart from that the whole package is what I expected - a pretty solid and well integrated thing that so far seems to perform well. Lots of control options, a decent UI on the machine itself etc is the reason I went with it.
    The print bed material seems to be pretty convenient.
     
  2. Ed Ferguson

    Ed Ferguson Active Member

    Joined:
    Sep 21, 2016
    Messages:
    272
    Likes Received:
    220
    Thanks for sharing Kilrah. Glad you were able to temporarily fix some issues well enough to enjoy some printing.

    I received an email last week from Brandon asking how things were going with my R2. Hopefully all owners get a similar email.

    I'm happy overall with the design and operation of the R2. It's a shame that many DOA failures are self-inflicted. As you know, the interior is packed tighter than Jed Clampett's truck. Too many parts (micro-switches, pogo pins, rods) getting damaged by stuffing 3 pounds of accessories into a one pound box. They'll need to sort it out fast because the average consumer will simply return the printer for a replacement, and warranty costs will skyrocket.

    Anyway - please continue to share what you're making and hopefully you'll get some replacement parts shortly.
     
  3. sgomes

    sgomes Active Member

    Joined:
    Dec 29, 2016
    Messages:
    136
    Likes Received:
    57
    That's odd, for me it works with Simplify3D. I just removed all scripts from the slicer and let Octoprint use its own, but it seems to honour the temperatures I set in the slicer.
     
    Ed Ferguson likes this.
  4. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    OctoPrint does not supplant any start up gcode. this is how it works and the preference

    On a successfully completed print
    1. OctoPrint will execute all code in Before print job starts
    2. Your sliced code will execute normally after that (all of it)
    3. On prints successfully finished OctoPrint executes all code in After print job completes
    On an aborted print
    1. OctoPrint will execute all code in Before print job starts
    2. Your sliced code will execute normally after that (all of it)
    3. When aborted (cancelled within OctoPrint) OctoPrint will execute all code in After print job is cancelled
    On a paused print
    1. OctoPrint will execute all code in Before print job starts
    2. Your sliced code will execute normally after that (all of it)
    3. When paused by OctoPrint (not paused by LCD or GCode) it will then execute all code in After a print job is paused
    4. When resumed by OctoPrint (not the LCD or GCode) it will execute all code in Before print job is resumed
    The other two OctoPrint scripts do not apply to print jobs.

    Do you see a pattern? At no time does OctoPrint do anything with sliced code other than execute every line that contains a command. There is nothing else it can do.
     
    mark tomlinson likes this.
  5. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    Completely aware of it - my point is that the "package" as it is supplied and supposed to be straightforward (i.e. the combination of Cura for Robo with the R2 profile and Octoprint as it is configured out of the box) results in quirky operation.

    As said in that state when I open Cura, set some temps, slice a model and send it to the printer it will print using the default 230/60 temps that are set in the Octoprint "Before print job starts" code instead, the temps I chose in Cura are never used, AND trying to adjust them during the print either through the front panel or through the Robo iOS app (or web interface) fails, they're somehow locked. If I comment out anything temp-related in that "Before print job starts" code then manual adjustment works, file temps are used, BUT the supplied Cura profile then does not handle preheating correctly.

    This can of course be made to work - my point is that it doesn't behave as you'd expect when using everything as supplied.
     
  6. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    A Benchy and a screen hood (the 5h print)

    20170629_100251.jpg

    20170629_100319.jpg

    20170629_113246.jpg

    20170629_100428.jpg

    Stylus holder came out nice too

    20170629_100311.jpg
     
  7. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    @Kilrah Then the issue is the Cura profile! OctoPrint does not do this or affect it in any way. And Gcode is Gcode so if I set bed temp to 60°C as the very first line of Gcode then 10 lines later issue another Gcode command that sets the bed to 50°C before I even start extruding, guess what temp I will be printing at?

    So look at the start up code, paste it here (both OctoPrint & Cura) and maybe it is something very obvious.
     
  8. OutsourcedGuru

    OutsourcedGuru Active Member

    Joined:
    Jun 3, 2017
    Messages:
    752
    Likes Received:
    141
    For what it's worth, the temp issue is what I'm seeing too on the Cura + OctoPrint combination when trying to print with the carbon fiber--infused PLA and a custom material profile. I just had to haunt the print and keep watching the temperature and manually re-adjust that during the early printing. I'll go to school on the GCODE eventually to see if this is Cura's fault.
     
  9. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    I'll have to give it a try again to confirm. But here's the default Octoprint Gcode already:

    Code:
    ; set to millimeters
    G21
    ; set to absolute mode
    G90
    ; zero extruder
    G92 E0
    ; turn off fans
    M107
    ;non blocking heatup of extruder and bed
    M104 S230
    M140 S60
    ; home all axis
    G28
    ; probe for bed autolevel plane
    G29
    ; pause for 2 seconds
    G4 S2
    ; move bed down 15mm
    G1 Z15 F300
    ; move to front left corner
    G1 X1 Y1 F7200
    ; heat to priming line temp
    M109 S230
    M140 S60
    ; move bed to printing position
    G1 Z0.3
    ; print 190mm priming line
    G1 X190 E15.0 F500
    ; move bed down
    G1 Z15 F300
    ; zero extruder
    G92 E0
    ; set movement speed
    G1 F7200
    
    There is nothing in the "start Gcode" box in cura. The start of a Gcode file looks like this:

    Code:
    ;FLAVOR:RepRap
    ;TIME:56234
    ;Filament used: 20.1248m
    ;Layer height: 0.1
    ;Generated with Cura_SteamEngine 2.5.0
    M190 S60
    M104 S190
    M109 S190
    ; -- START GCODE --
    
    ;LAYER_COUNT:256
    ;LAYER:0
    M107
    G0 F2400 X51.839 Y44.54 Z0.3
    ;TYPE:SKIRT
    G1 F1350 X52.182 Y44.163 E0.02899
    G1 X52.578 Y43.845 E0.05787
    G1 X52.839 Y43.686 E0.07526
    G1 X59.414 Y40.066 E0.50214
    G1 X64.022 Y37.128 E0.81296
    G1 X68.94 Y33.575 E1.15803
    ...
    
     
    #9 Kilrah, Jun 29, 2017
    Last edited: Jun 29, 2017
  10. OutsourcedGuru

    OutsourcedGuru Active Member

    Joined:
    Jun 3, 2017
    Messages:
    752
    Likes Received:
    141
    So the OctoPrint start looks like it's commented out and the Cura-generated gcode looks like this:

    Code:
    M104 S190 ; Set the current extruder's hotend temperature (celsius)
    M109 S190 ; Wait for the current extruder's hotend to reach target temperature
     
  11. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    The commenting out was mine to get thigns to work. Forgot to remove it when posting, corrected now.
    What cura does with the 2 successive extruder instructions is pretty stupid - some time would be gained if the bed one and the first extruder one were swapped. That way you'd start extruder heating and bed heating at the same time, then once bed is ready wait for extruder to be hot if it isn't yet so that everything is correct before continuing. Now it doesn't even start heating the extruder until the bed is ready.

    Haven't found where to change that yet, it doesn't seem to be in the app settings, probably need to dig into config/profile files.
     
    #11 Kilrah, Jun 29, 2017
    Last edited: Jun 29, 2017
  12. OutsourcedGuru

    OutsourcedGuru Active Member

    Joined:
    Jun 3, 2017
    Messages:
    752
    Likes Received:
    141
    Some people (coders) just think in a linear fashion and that's how they write it. It's entirely possible, though, that someone was sitting there with an ampmeter and watching the high-water mark and was trying to stagger the load. Dunno.

    As for changing it, you're either looking at modding the Cura code itself or using a post-processing script which you can write to look for gcode and change it.
     
  13. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    I was expecting Cura to be designed in a modular fashion, where the Gcode output would be laid out in a template so that this could be edited, a bit like Fusion 360's CAM post-processors.

    From a quick look it seems quite modular indeed, but maybe not to that level. Since Robo have a customised version they could probably have that changed though if there is no other way.

    Anyway what I've done is moved the Octoprint startup Gcode to Cura (bar the temp instructions that I've removed), and things work satisfactorily now since the Cura "startup Gcode" isn't exactly startup and is executed after temps are set and reached.
    I'll try to have a look/confirm the behavior I initially noticed since it makes no sense at all and could indicate a bug in Octoprint or the Robo interface/firmware but that will have to wait for the current 15+h print to finish.

    RR_Fan_With_Supports_20170629202110-1681.jpg
     
    #13 Kilrah, Jun 29, 2017
    Last edited: Jun 29, 2017
  14. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    @Kilrah other than cosmetics there is nothing special about the Robo version of Cura. It isn't even based on the current Cura release.

    Just so we are clear, using M104 and M140 (lines 10 & 11 in OctoPrint script) sets hotend and bed temperatures respectively and then immediately returns control to the host so it can continue to execute commands. It works, but something to consider is that you could actually start printing before the hotend or bed is up to temp. The while still in the OctoPrint startup script the temp is set again with M190 and M140 (lines 23 & 24) M190 is a set bed temp and wait command, control is not returned to the host until the heating is complete, M140 does the same for the hotend.

    Now on to Cura, If you do not have any commands that adjust temps in the startup script. Cura (as well as Slic3r and S3D by the way) is smart enough to insert them for you. So leaving them out of Cura's start up script does not do what most people think it does. Cura sets the temp, Cura always sets the temp at the beginning of the sliced file. The only thing you have control over is whether or not Cura does it on its own, or you put it in the yourself. So Cura sets bed temp and waits for it to complete, then it sets hotend temp and returns control then resets hotend and waits for that command to complete.

    The reason most people do not start up both heaters at the same time is when an undersized heater is used for the bed it can take a very long time to heat for certain filaments. Example, Nylon or Polycarbonate filaments may require bed temps as high as 100°C with extruder temps in the 230-250°C range. The hotend generally heats much faster, if you start them both up at the same time but use M140 for the bed followed by M109 for the hotend it will set the bed temp and while it is heating it will set and wait until the hotend is up to temp. The key here is, the host no longer monitors the bed temp for target temperature the way you might expect. As soon as the hotend is at temp it moves on, usually to start printing and the host simply doesn't care if the bed is still not up to temp yet.

    Also depending on how the firmware is set up there can be a significant power draw when both heaters are trying to reach target temps. This shouldn't be the case in the R2 since they are using PIDs for both bed and hotend and I believe the default is 75% power max while setting temps. Bang-bang is 100% on 0% off in alternating cycles.
     
  15. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    Yup, perfectly clear on that. The whole point of my posting is that it somehow does not behave as it's supposed to. We agree that the "to be printed" Gcode (the file) isn't supposed to be read before the Octoprint start Gcode has finished executing, right?

    I've returned things back to default and haven't been able to reproduce the impossibility to adjsut temps manually, but there's still something weird. I have sliced a file with 190/50 temps set, which is confirmed to be correct in the output file.

    Now start print - Printer starts heating to the "standard" 230/60 as can be confirmed on the front panel and starts the homing/autolevel procedure during which one can't see the evolution of the temps becasue the board is "too busy" to continue sending them while it's doing it's thing (another pet peeve of mine that so many commands are blocking even that and that you can't even cancel them, not related to Robo though). Then as soon as the autolevel is finished the temps are non-blockingly set to 190/50 and the priming line starts printing straight away while the temperatures are going down. Then printing starts, but without waiting for temps to be those specified in the file.

    This makes no sense.
    Temps from the file are starting to be considered right in the middle of the Octoprint start Gcode, and non-blockingly while the actual Gcode in the file is blocking. Which is why there has to be something that "manipulates" stuff instead of just executing lines as we would expect it to.

    Unrelated but the 15h print failed - the spool of blue PLA is pretty awfully wound and will consistently make a knot after an hour or so of printing without intervention.

    Use M190 for the bed then :)

    On a side note I just received my tracking number from Robo, cool :D
     
    #15 Kilrah, Jun 29, 2017
    Last edited: Jun 30, 2017
  16. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    @Kilrah I always used M190 for the bed, just to be safe when I had the OEM bed heater.

    If you are willing to experiment try adding an M400 to the end of the OctoPrint start before a print job code. That will force the host controller to execute all commands in the command buffer before executing any code in the sliced file. If that doesn't change the behavior try to add this line at the end of the OctoPrint code G4 S2 (Dwell for seconds).
     
  17. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    Yep, was starting to think most of the issue is confusion from unsynced displays due to buffering, will try M400.

    Octoprint probably displays set temps as soon as it has sent new commands out, but since those are buffered on the mainboard there can be minutes until they actually get executed. So while the board is still busy with the homing and bed level cal Octoprint has already finished sending the startup Gcode, and already sent the first few lines of the file inclusing the temp commands so that's what it now displays as set temp even though it's actually not the case at all yet.

    Actually I prefer keeping Octoprint startup Gcode empty and adding that including the priming line to Cura, because that way it's done at the proper temp. When printing PLA having the priming line done at 230° causes excessive oozing that causes failed print starts.

    Apart from that one more failed print due to disconnected bed, and one of my pogo pins "died" the way some have already reported with the springy center not being springy anymore.
    I'll do a post mortem but I'll guess with vibrations the 2 main parts that are a bit too loose sometimes end up not really touching each other anymore, which causes all the current to flow through the spring instead and melting it.
    This seems like it will become a major issue.

    I'll have to try and sort out a fix before I can do anything more.
     
  18. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    Look at the temperature graph in OctoPrint as it will show you the SET temperature (what it told it to do) and the actual temperature.
     
  19. Kilrah

    Kilrah Well-Known Member

    Joined:
    Apr 18, 2017
    Messages:
    498
    Likes Received:
    332
    Thing is, during these confusing moments the measured temperature does not update.
     
  20. OutsourcedGuru

    OutsourcedGuru Active Member

    Joined:
    Jun 3, 2017
    Messages:
    752
    Likes Received:
    141
    It wouldn't surprise me if the Raspi in some /sys/class/gpio/gpio4 or similar folder doesn't have the raw temperature in celsius*1000 or something like that. In theory, you could ssh into the Pi and watch the file.
     

Share This Page