Question for you Octoprint users…I just set it up and have it communicating with my printer, but for the life of me I can’t get it to home my Z axis.
X and Y home fine, and I’ve inverted the Z axis so everything moves like it should. But homing on Z just moves down on Z like it’s going to home and stops. I have a proximity probe and everything works fine within S3D.
I’ve checked O Pi’s forums, done death by Google, and just can’t seem to find the fix. I sliced in S3D and loaded to try to print as well, and the Z axis is off. There’s no gcode entered into the boxes, and I’ve disabled the cura plugin (just in case even though I’m not using it to slice)…thoughts?
I’ll also add that manually entering G code into the terminal exhibits the same issue (G28 Z, etc.) where it doesn’t lower enough to trigger the proximity sensor.
There really should be no difference between Octoprint sent homes and other homes that I know of. If the gcode sent from the Octoprint terminal does not work then I do not see how S3D would work if the home commands from the terminal do not.
@NathanielStenzel , yup, don’t disagree which is why I have a few less strands of hair right now. Basically have a RAMPS board running latest marlin and no problems from S3D doing manual control/homing let alone when printing.
When homing via Octoprint the terminal shows where it sends a G28 Z and shortly after sends G90 (huh?).
Can S3D export gcode? What would happen if you sent such gcode through Octoprint? Can you read such gcode and see if it has the same commands as what you were sending?
G90 just makes it clear that you are not moving in relative terms but to a specific coordinate when you say to move. This is good. Especially so if you pause, home, resume during a print to try to fix skipped steps.
yes, I had sliced and exported from S3D to see what would happen with the print knowing that I had my homing and auto leveling scripts in there. So it went through it’s process before the print but the Z axis was never homed correctly.
It basically moves like 10mm and stops as if it triggered the Z endstop but it’s no where near the bed.
Do you have a switch or a touch probe or a capacitive or a field effect sensor to let you home Z? Do endstops behave with M119? That should tell you their status.
In further checking I’m seeing where it shows my Z min being triggered within Octoprint even though the proximity sensor is no where near the bed and is not being triggered. S3D shows everything open as it should until being homed and then it shows the correct endstops to be triggered.
I swapped out my probe (LJ12A3-4-Z/BY) with a mechanical endstop and Octoprint now sees the endstop as being open (as it should).
So not sure why Octoprint sees it one way while S3D works fine. I know my voltage level is a little on the low end for a binary high, but this should affect any SW connected to the RAMPS since it would basically be receiving a yes/no, high/low trigger…no?
Do you have it wired to the Z endstop? I think some boards have a special place to hook up proximity sensors. Maybe yours does. I never used one myself.
Thanks to all who offered feedback, but thought I’d follow-up on the fix. I had suspected my voltage level was borderline on the inductive probe (mainly due to not having the right resistors and trying to get by with what I had).
So tossed out the voltage divider and replaced with a diode, enabled internal pull up and now voltages are inline with expectations…and now Octoprint is happy and working fine. Still don’t understand how or why S3D was able to work as it should be working off of the same logic received from the RAMPS.
Was a Raspberry Pi only being powered by the system when using Octoprint and not when S3D was controlling things? If so, maybe it was taking up too much power for the old voltage divider setup.