Solved Problem with Z Offset on LCD Display

It’s been a while since I’ve posted here. Back around 2015, I brought my R1 to the office so everyone could use it, and after a couple of months of heavy use, so many things were wrong with it that I didn’t have the urge to fix them all. It got stuck on a shelf and forgotten.

A couple of months ago, I got the 3D printing bug again because there were a lot of little things that I wanted to print, so I bought a new printer that works pretty great. After I’d been using it, I decided to get the old R1 out of storage and fix it up for my kids to use.

After replacing a bunch of parts that were broken and tuning it all up, it’s printing beautifully, better than it ever did. The prints are absolutely perfect on it. The shell is a bit yellowed, but mechanically, it’s a beauty.

Today, I installed a 12864 display module and made the firmware edits to get almost everything working well, including inverting the encoder. I’m using the latest official firmware from Robo’s website with a few tweaks here and there.

The last remaining issue is when I try to print from the display’s SD card slot. For some reason, the z axis wants to go way too low and grinds against the bed.

I’ve tried to edit the z offset on the display, but it won’t allow me to adjust it below +000.05mm. My printer needs to have a z offset of around -1.0mm, but the dial won’t go below the 0.05mm setting. I can dial it more positive as far as I want, which lowers the nozzle even further into the bed, but I just can’t go the other way, like there is a hard limit. The printer seems to ignore any z offset setting I have in the gcode, so it’s not an easy slicer fix.

I’m sure that this is a setting in the firmware somewhere, but I can’t seem to find it. Does anyone have any insight or a solution for me?

 

Thanks for the link, but that wasn’t my issue.

I’m fairly familiar with getting these things tuned. The only problem that I was having was that I couldn’t get prints to run from the SD card in the new display that I’d just installed yesterday.

I didn’t have any issues printing via octoprint, which is what I’d been up until yesterday.

My new Creality printer lets me store the z offset in the eeprom, so I don’t need to adjust my slicer settings. I was attempting to do this in the Robo.

The settings that I need to put in the slicer was -1.0mm. I was trying to adjust it on the display, but the knob wouldn’t adjust any lower than +0.05mm. I could go as high as I wanted, but no lower than 0.05.

Even with the z offset in the gcode, the nozzle just ran across the bed until layer 4, then it would print fine.

Earlier today, I flashed the 1.1.1 firmware I found on here, then spent a couple of hours getting the display working and everything configured.

The new firmware was still dragging the nozzle across the bed, so I experimented a bit and found that the display z offset is inverted compared to the slicer. I had to set it to +1.0mm to get it to lay down the first layer right. The printer just finished printing a calibration cube from the SD card, and it looks pretty perfect.

The only thing I have left to do on this is make some better brackets for my lead screw upgrade. I’ve tried a few from Thingiverse, but none of them are perfect yet.

 

I was originally using stock firmware. I agree that the z offset in the GCode should have worked, but it didn’t. I’m using the exact command that you posted.

If I uploaded the GCode to octoprint, it would print perfectly. If I put the exact same file on the SD card, it would drag the bed. I have no idea why it would treat the exact same file differently, but it did.

My cal cube was still a tiny bit close on the bottom layer, so I can still go up a hair, but that’s just being picky at this point. I’ve been messing with this printer so much lately that it is printing even better than my new one now.

 

I got busy and didn’t work on it again until today, and I decided to just start from scratch.

I adjusted the Merlin 2.0 firmware posted in here for my configuration, and everything is working great.

I don’t know what the issue was before on the other firmware, but it is now printing the first layer properly using the same gcode file. I didn’t have any startup gcode in the octopi, so that wasn’t causing it. It was only an issue when printing from the SD card slot on the display board.