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

Solved Uneven First Layer on one side of bed

Discussion in 'Troubleshooting' started by WizarDru, Oct 27, 2016.

  1. WizarDru

    WizarDru Member

    Joined:
    Aug 31, 2016
    Messages:
    78
    Likes Received:
    34
    Geof, I'll be glad to when I get home. I'm using the default GCODE that Simplify3D uses. I may have added a G28 command, but I haven't modified anything since I first got the printer, so it should be pretty vanilla. My expectation is that I've messed up the x-axis trigger placement somehow. I can experiment with moving the nozzle closer to the bed, but it feels like if I'm going over -0.6 that something must be amiss somewhere.

    For reference, I tried two different PLAs, printing at 200C, bed at 50C. Tried with both hair-spray and glue stick just to make sure it wasn't the new can I bought. Material is going down, but it's not really adhering and comes off. It looks (to the naked eye) that the nozzle is just too far above the bed. I just got back from a trip last night, so wasn't inclined to spend more than an hour messing with the printer. :) Really hoping I can get this tweaked, 'cuz I feel like I'm almost there in getting the printer back to functional.
     
  2. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,421
    Likes Received:
    7,299
    One of my Robos is at -0.9 and the other at -0.5

    Your Mileage May vary.
     
  3. Geof

    Geof Volunteer Moderator
    Staff Member

    Joined:
    Nov 9, 2015
    Messages:
    6,728
    Likes Received:
    2,328
    I'm curious is your M565 Z-x.xx is correct (x.xx is your numbers )
     
  4. WizarDru

    WizarDru Member

    Joined:
    Aug 31, 2016
    Messages:
    78
    Likes Received:
    34
    I'll confirm when I get home. I do know that when I manually home the z-axis on both the left and right side of the bed, it appeared to be home correctly, unlike before, where there was definitely a gap if I moved across the bed. If the solution turns out to be just changing the G-Code, I'm OK with that...I just want to make sure that's actually the issue.
     
    Geof likes this.
  5. Geof

    Geof Volunteer Moderator
    Staff Member

    Joined:
    Nov 9, 2015
    Messages:
    6,728
    Likes Received:
    2,328
    If its homing correctly and the issue is adhesion. I'd guess the z offset number needs to be smaller but it has to be entered correctly or it gets ignored
     
    mark tomlinson likes this.
  6. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,421
    Likes Received:
    7,299
    Yea, even using lower case letters (m565) is a no-no :)
     
  7. danzca6

    danzca6 Well-Known Member

    Joined:
    Jul 27, 2015
    Messages:
    2,161
    Likes Received:
    1,077
    If you see your offset needing to be too low, I would suggest doing an extrusion calibration to make sure you aren't under extruding. Or your extrusion percentage might be too low in the slicer software.
     
  8. WizarDru

    WizarDru Member

    Joined:
    Aug 31, 2016
    Messages:
    78
    Likes Received:
    34
    Okay this is the entirety of my startup script:

    G28 ; home all axes

    G29 ; probe the bed

    G1 Z5 F5000 ; lift nozzle

    M109 S[extruder0_temperature] ; set the extruder temp and wait

    G28 X0 Y0 ; home again to start wipe

    G1 X20 Z0 F4800 ; wipe


    So not much going on there. I've gone down to -0.8. This is controlled through Simplify3D, so I don't manually issue the M565 command. Further, when I adjust it, 1MM IN EITHER DIRECTION, it's still doing it. As a test, I tried printing from Matter Control (at default 0 offeset)....and it's printing properly. So that means that the problem must be something in Simplify3D, which has never happened. I wonder if the latest update did something. Odd.

    Huh. Wondering if the print temperature is the difference? I set the temperature in S3D to print at 195 instead of 210. Maybe that's it. I'll test.
     
  9. danzca6

    danzca6 Well-Known Member

    Joined:
    Jul 27, 2015
    Messages:
    2,161
    Likes Received:
    1,077
    Ok, so could you save your sliced model gcode to a file and make sure S3D is adding the M565 command properly? Something tells me it may not be doing what you are hoping. My personal preference is to just put the M565 Z-0.8 after the G28 command and before the G29. Then I know it is correct.
     
    Geof and WizarDru like this.
  10. WizarDru

    WizarDru Member

    Joined:
    Aug 31, 2016
    Messages:
    78
    Likes Received:
    34
    I think you may be right. I just saved some toolpaths for the 3mm test square and it didn't have an M565 command in it....which seems wrong. I suspect either I changed something or the most recent update did something. I'll check with Simplify3D to see what they say.

    The good news is that my calibration print looks fine via MC, except for a minor issue on one corner.
     
  11. ROBOLabs

    ROBOLabs Moderator

    Joined:
    Sep 21, 2016
    Messages:
    31
    Likes Received:
    52
    Hi WizarDru, if you're using Simplify3D, I would advise you to use this start g-code:

    G28 ; home all axes

    G1 Z5 F5000 ; lift Z by 5mm

    G29 ; run auto-level

    Anything else in the start g-code is extraneous, so I would delete everything and copy and paste the start g-code above.

    As far as Z-offset, the majority of the printers in the shop at Robo HQ print well at Z-0.9--I would give that a go. Keep in mind that if you're trying to set your Z-offset by issuing an M565 command, you are not doing anything other than calling out the current Z-offset value. In order to actually set a new Z-offset, you have to issue an M575 command, like so:

    M575 Z-0.9

    That will hard-code the Z-offset in the EEPROM. If you're still getting an uneven first layer along the X-axis, the weight of the stepper on the right side of the X-axis assembly is to blame; you can compensate for this imbalance by adjusting the Z-endstop brackets up or down until both of the limit switches engage and disengage simultaneously. Oh, and keep an eye on the "bunny ears" of the Z-endstop brackets--that's what was giving you so much trouble when trying to pop the coupler nuts back into their respective seats. Personally, I don't bother with getting everything absolutely perfect, I simply watch the first layer as it goes down, then adjust the appropriate leadscrew up or down a click or two as needed. I guess it becomes second nature when you've done it thousands of times. :D

    As far as print temps in Simplify, if you're using Robo 3D filament, 195*C is optimal. That's the print temp that I use in my S3D print profile. Let me know how this works out for you.
     
    WizarDru and Rigmarol like this.
  12. Geof

    Geof Volunteer Moderator
    Staff Member

    Joined:
    Nov 9, 2015
    Messages:
    6,728
    Likes Received:
    2,328
    @ROBOLabs , curiosity has the best of me, wouldn't you want the z offset to be able to be changed based off your factory file in simplify 3D. Example being- larger or smaller nozzles require different z offsets, certain materials require more or less offset, adhesion type changing (buildtak vs hairspray etc). I am a much bigger fan of the M 565 command. Storing information into EEPROM can become an issue if its forgotten about. :D
     
    #32 Geof, Nov 8, 2016
    Last edited: Nov 8, 2016
    mark tomlinson likes this.
  13. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,421
    Likes Received:
    7,299
    Geof likes this.
  14. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    There is a lot of incomplete information in the RoboLabs response, first as noted the incorrect command, second EEPROM is not involved in the scenario presented. All you are doing by issuing the correct M565 Zn.nn command is placing that value in RAM so that for the current session you can use whatever value you set. This M565 value will not survive a power off or system reset.

    There are three basic places to set this value. The first is in firmware which requires that you edit a file (Configuration.h), recompile and upload the firmware. A second way is to figure out the offset you want and include it in your startup g-code. It is customarily placed between a G28 (homing command) and a G29 (auto-leveling command). A third way is to issue the command from a terminal screen and then save the value to EEPROM, if enabled.

    Just so you know how this works.
    • If it is in Firmware, this will be the default value used unless any of the following are true, the value is stored in EEPROM or the value is included in the start-up g-code for every print. This value only resides in RAM and will be reset every time the firmware is initialized. This value is only read and inserted in RAM at Firmware initialization.
    • If it is in EEPROM, this value will be used unless the following is true, the value is placed in start-up g-code for every single print. Upon firmware initialization all EEPROM values are read and placed in RAM overwriting any values set in Firmware. This value is only read immediately after Firmware initialization.
    • If it is in start-up g-code it will be reset for every single print, regardless of any other location it may be stored in. Typically placed between homing and auto-leveling commands. This method only stores the value in RAM and does not survive a firmware reset.

    All this just to explain that it is up to you to decide which method you want to use. Also to understand how one method may affect the print output based on behavior.

    Personally, I have more than one printer and they use offsets very differently so I do not put it in the start-up g-code nor in the Firmware source. This allows me to slice it once and use it over and over on either printer. Since the actual value rarely changes I chose to put it in EEPROM, so that way I don't have to worry about or edit existing firmware. If I need to change it I do that from a terminal window attached to the printer and resave the value to EEPROM. There are plenty of other threads that explain how to connect via terminal and issue g-code or m-code commands
     
    #34 WheresWaldo, Nov 8, 2016
    Last edited: Nov 8, 2016
    WizarDru, Geof and mark tomlinson like this.
  15. WizarDru

    WizarDru Member

    Joined:
    Aug 31, 2016
    Messages:
    78
    Likes Received:
    34
    Thanks for the all info, everybody.

    So in this case, do we think that's what happening here? I've attached the gcode file that Simplify3D generated when trying to print the 3MM calibration cube I use for basic testing. That generates this kind of result (apologies for the shakycam). Changing the Z-offset in the Gcode tab (which normally works fine) doesn't appear to have any noticable effect....changing it from -1.5mm to 1.00mm shows almost no difference, which suggests it's being totally ignored (or at some point I should be dragging the bed at the very least).

    To confirm it wasn't just temperature (which I was sure it wasn't) I did try printing at 210 in S3D, since that's the default in MC. No difference (nor did I expect one, as I'd printed before on the R1+ at that temp with no problems with adhesion). As a test, I was able to successfully print a Pacman Ghost last night with no problems (other than minor extrusion issues I've seen before that probably is just a result of needing to season the printer again).

    I'm glad that it's working in MC, but why would it work in one and not the other? Is MC explicitly sending a 0.0 offset command while S3D suddenly is not? My main concern is that my fixing on the X-axis threw something off, other than just a simple setting in S3D.
     

    Attached Files:

  16. Geof

    Geof Volunteer Moderator
    Staff Member

    Joined:
    Nov 9, 2015
    Messages:
    6,728
    Likes Received:
    2,328
    Add the

    M565 Z-.80; initial z offset


    gcode to the start up script. Remove it from the global.
     
  17. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    The Global G-Code Offsets in the G-Code tab of Simplify3D does not do what I believe most people think it is supposed to do. You would think that it adds the commands to do an offset in the specified amounts, but it doesn't. It actually adjusts the calculated coordinate numbers within each g-code move. This is totally different that what is being described here.

    If you want to test this yourself, print a 10 mm x 1 mm circle in the middle of your bed. Now go back and adjust the S3D process to change X and Y offsets from 0 to 20 each. Reslice and reprint the newly sliced g-code, you won't even need to remove the original disc you printed, because the new one will be moved 20 mm in both X and Y.
     
    Geof and mark tomlinson like this.
  18. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,421
    Likes Received:
    7,299
    I agree, you should add this to your startup GCode block and be done with it.
     
    Geof likes this.
  19. WheresWaldo

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

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    Don't blame MatterControl or S3D about how they implement the global Z_Offset. Remember that these slicers are not built by Robo nor are they specific to Robo. They must work with other G-Code compatible firmwares. Some use M851 some use M565 some don't have an m-code to adjust offset so they do it their own way. That is why EEPROM, start-up g-code, firmware are better more predictable ways of setting this variable.
     
    Geof likes this.
  20. WizarDru

    WizarDru Member

    Joined:
    Aug 31, 2016
    Messages:
    78
    Likes Received:
    34
    I'm just trying to understand and solve my issue. I'm not trying to blame anyone for anything. Whenever I've used the G-code offset before in S3D, it worked in the same way as Cura, or so I thought. My main focus is just making sure I'm actually fixing the problem.

    I'll try adding that M565 command and see if that fixes it.

    Thanks!
     
    Geof likes this.

Share This Page