incorrect z homing SOLVED, bad s3d profile, thanks everyone!

[SIERRA086]

I normally do my slicing with s3d and then upload it to the pi.

When the print starts the printer attempts to home z as it should per starting gcode. The printer doesn't do that nice little easy bounce you get when it homes z properly (The bed lowers, hits the switch, and picks up a little). Instead - the bed lowers and comes to a hard halt seemingly all the way down because I can hear the z switch trip but its like the bed goes till it cant go anymore. After that happens the printer (following its gcode) picks the bed back up toward the nozzle to begin the print process, when the bed reaches its highest point and the nozzle goes to extrude and do the pre-print wipe you can see that the bed is now about 3-4mm too low in relation to the nozzle. At this point clearly something is wrong and I cancel the print - I've let it go a couple times and the print turns into a disaster in seconds.

This happens often between prints and after starting a new print when you previously canceled a print. I have never experienced this behavior when printing directly from s3d - I really need to switch over to s3d control again to confirm this and rule out a possible bad z switch.

With all this said, I have been using a work-around to get my octopi to print for me. I can reasonably predict the behavior described above so what I have to do is - before beginning a new print I use the control tab in octopi to home the z axis myself. I click the home button a couple times until I see the printer home properly as it should (nice easy "bounce" after the z switch is tripped). I can then start the print and everything works great.

However, there have been a few times when the printer just refuses to home z properly while connected to octopi. I can click home z all I want but the platform just seems to ignore the z switch even though I can hear the switch activate and instead I get a hard bottom-out effect like I described above. To fix this all I have to do is click disconnect and then reconnect within octopi and then operation is normal again.

If you were able to read all of that I appreciate it and thank you for your time. I'm just wondering if there is some simple answer to my problem and if anyone else has had the same happen to them.

[ednisley]

rule out a possible bad z switch

The switch is fine, but the Z-axis machinery needs some attention. If you haven't cleaned & lubed the Z-axis guide rods and leadscrew recently, now's the time to catch up on that duty:

http://makergear.wikidot.com/m2-lubrication

What you're seeing is a stepper motor being unable to provide enough torque to move the platform. Assuming that you haven't changed the slicing parameters and haven't re-flashed the RAMBo firmware, then "what's new & different" is an increased mechanical load on the motor.

There are a few other things to investigate, but start with a good cleaning & lube.

[SIERRA086]

rule out a possible bad z switch

The switch is fine, but the Z-axis machinery needs some attention. If you haven't cleaned & lubed the Z-axis guide rods and leadscrew recently, now's the time to catch up on that duty:

http://makergear.wikidot.com/m2-lubrication

What you're seeing is a stepper motor being unable to provide enough torque to move the platform. Assuming that you haven't changed the slicing parameters and haven't re-flashed the RAMBo firmware, then "what's new & different" is an increased mechanical load on the motor.

There are a few other things to investigate, but start with a good cleaning & lube.

Thanks for the quick reply! I actually just did my first 250 hour service last weekend. Everything cleaned up and lubed up nicely. I am running one of insta's MIC 6 bed plates which is heavy compared to the standard glass. I'm going to throw out a guess and I bet you'll tell me that extra weight is my problem

A question that comes to mind is that if too much mechanical load is the problem then why can I get it to work reliably with my described work-arounds? I'm not saying you are wrong but it just seems that if I had too much load then the bed wouldn't function at all.

[ednisley]

that extra weight is my problem

That would be one of the "few other things to investigate": if you didn't increase the motor current, then the motor must accelerate more mass with the same torque.

why can I get it to work reliably with my described work-arounds?

We humans are extremely good at finding patterns, even where none exist. If the motor torque is just barely able to accelerate the platform without stalling, then it'll work sometimes and fail sometimes, while you make up all manner of stories explaining why it does what it does. We have all done exactly that!

You can (and probably should) reduce the maximum Z-axis acceleration and homing speed, which you can do in the G-Code header with M202 and M210 or, for the brave & daring, by tweaking the defaults & recompiling the firmware.

[SIERRA086]

that extra weight is my problem

That would be one of the "few other things to investigate": if you didn't increase the motor current, then the motor must accelerate more mass with the same torque.

why can I get it to work reliably with my described work-arounds?

We humans are extremely good at finding patterns, even where none exist. If the motor torque is just barely able to accelerate the platform without stalling, then it'll work sometimes and fail sometimes, while you make up all manner of stories explaining why it does what it does. We have all done exactly that!

You can (and probably should) reduce the maximum Z-axis acceleration and homing speed, which you can do in the G-Code header with M202 and M210 or, for the brave & daring, by tweaking the defaults & recompiling the firmware.

Thank you again,your input is appreciated. I'll see what I can do!

[ksevcik]

I have a contrary opinion. It sounds very much like the z motor isn't running a homing command, just doing a move and running into the bottom of the z axis. 3 to 4mm sounds very much like the home offset for a printer with a mic 6 plate. By default the limit switches are disabled during normal operation, so it's entirely possible to run into them. If your bed runs into the lower limit and then makes a horrible buzz for a few seconds, that's the stepper skipping since it can't move any farther. Also, homing speed is usually different from most rapid speeds. If the bed moves down slower when it "bounces" properly than when it hits and stops, that's a sure sign that it's not actually homing.

I don't run octopi yet, so I can't say why it would do this, but I wouldn't rule out the possibility that octopi is futzing with the guide, or s3d is exporting different guide than it sends live.

[SIERRA086]

I have a contrary opinion. It sounds very much like the z motor isn't running a homing command, just doing a move and running into the bottom of the z axis. 3 to 4mm sounds very much like the home offset for a printer with a mic 6 plate. By default the limit switches are disabled during normal operation, so it's entirely possible to run into them. If your bed runs into the lower limit and then makes a horrible buzz for a few seconds, that's the stepper skipping since it can't move any farther. Also, homing speed is usually different from most rapid speeds. If the bed moves down slower when it "bounces" properly than when it hits and stops, that's a sure sign that it's not actually homing.

I don't run octopi yet, so I can't say why it would do this, but I wouldn't rule out the possibility that octopi is futzing with the guide, or s3d is exporting different guide than it sends live.

Thanks for the reply! I'll have to pay attention to it's speed when the problem happens. It does look like I was incorrect in blaming my octopi installation. I just switched back to s3d entirely and the issue happened there as well! I should have tested further before jumping the gun and trying to blame one thing right away. With my next print I will try to reduce the maximum Z-axis acceleration and homing speed as ednisley suggested and see what happens.

[SIERRA086]

Still no luck. I reduced the speed and acceleration of the z-axis, I reset the starting height and releveled the bed, and I even rewrote my starting gcode sequence from the default sequence to have the z axis home separately and slowly after x and y home.

Next I am going to try switching back to my original glass bed to reduce the weight and see if that solves my problem. After that - if the problem is still presenting itself - I'm going to replace the z endstop switch after I try adjusting its position up a few millimeters from where it sits now.

[3dPrintingMD]

Here is what I would do.

1) Using Octopi - Test the homing of axis. All of them.

2) Using s3d - make a new gcode of a print, and then upload it to octopi and print from there.

Report back.

I'm wondering if the S3d setup info is incorrect.

[SIERRA086]

Here is what I would do.

1) Using Octopi - Test the homing of axis. All of them.

2) Using s3d - make a new gcode of a print, and then upload it to octopi and print from there.

Report back.

I'm wondering if the S3d setup info is incorrect.

Hi and thanks for taking a look at my problem.

Ive done this - a lot - x and y are fine, Z homes fine most of the time but the problem does show itself at times when I manually home z. This is in both octopi and s3d that the problem displays itself. I had to correct myself earlier in the thread and now I understand its not a problem related to octopi because it happens no matter what software I use.