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

Ask the MakerGear community for assistance...
3dPrintingMD
Posts: 277
Joined: Fri Oct 02, 2015 5:37 am

Re: incorrect z homing behavior

Post by 3dPrintingMD » Fri Dec 02, 2016 3:16 pm

Not sure how comfortable you are with things, but if this was me, here is what I would do.

1) Get the correct firmware for the machine from the Wiki.
2) Delete all my profiles in S3D. (You can save them to reference).
3) Configure S3D for the Makergear using the configuration wizard.
4) Make a new object and print it.
M2 - V4, MIC-6 Build Plate, Astrosyn Damper's(X/Y), Rev. E, Geeetech LCD

S3D - FFF Settings https://forum.simplify3d.com/viewtopic.php?f=8&t=2367
Print Quality Troubleshooting https://www.simplify3d.com/support/prin ... eshooting/

User avatar
ednisley
Posts: 1188
Joined: Fri Apr 11, 2014 5:34 pm
Location: Halfway up the Hudson
Contact:

Re: incorrect z homing behavior

Post by ednisley » Fri Dec 02, 2016 3:38 pm

SIERRA086 wrote:the problem does show itself at times when I manually home z
That evidence eliminates everything other than mechanical problems or firmware settings; the slicer and the solid model have nothing to do with it.

Verify that the Z-axis moves smoothly over the entire range as you turn the leadscrew by hand, with the power turned off. If it doesn't, then fix that.

If you changed the firmware during this adventure, fetch the correct version, reload it, and test to see whether the Z-axis works correctly during manual homing. If so, you're done, but the default acceleration is probably too high.

If (as expected) it fails during manual homing, edit the firmware to reduce the maximum and default Z-axis acceleration values by a factor of 20 (for example: if you now have 10000, change it to 500), reload the firmware, and verify that manual homing works correctly. The Z axis will be sluggish, but that's part of the debugging process.

That should let the Z-axis home reliably. If so, then increase the Z-axis acceleration by a factor of 2 (500 becomes 1000) and re-test. Repeat that until homing fails, at which point the acceleration will be slightly too high. Now, divide that acceleration by 2 (8000 becomes 4000), reload the firmware, re-test, and it should work perfectly with the maximum acceleration your hardware can support.

Basically, that nice, heavy aluminum plate requires too much motor torque, so you must reduce the acceleration to compensate. Mechanical misalignment / crud / lack of lube make the problem worse and less acceleration makes it much better; fix both of those problems and it'll be as good as you can get.

Changing anything else is a diversion ...

SIERRA086
Posts: 29
Joined: Mon Oct 03, 2016 1:36 pm

Re: incorrect z homing behavior

Post by SIERRA086 » Fri Dec 02, 2016 7:48 pm

ednisley wrote:
SIERRA086 wrote:the problem does show itself at times when I manually home z
That evidence eliminates everything other than mechanical problems or firmware settings; the slicer and the solid model have nothing to do with it.

Verify that the Z-axis moves smoothly over the entire range as you turn the leadscrew by hand, with the power turned off. If it doesn't, then fix that.

If you changed the firmware during this adventure, fetch the correct version, reload it, and test to see whether the Z-axis works correctly during manual homing. If so, you're done, but the default acceleration is probably too high.

If (as expected) it fails during manual homing, edit the firmware to reduce the maximum and default Z-axis acceleration values by a factor of 20 (for example: if you now have 10000, change it to 500), reload the firmware, and verify that manual homing works correctly. The Z axis will be sluggish, but that's part of the debugging process.

That should let the Z-axis home reliably. If so, then increase the Z-axis acceleration by a factor of 2 (500 becomes 1000) and re-test. Repeat that until homing fails, at which point the acceleration will be slightly too high. Now, divide that acceleration by 2 (8000 becomes 4000), reload the firmware, re-test, and it should work perfectly with the maximum acceleration your hardware can support.

Basically, that nice, heavy aluminum plate requires too much motor torque, so you must reduce the acceleration to compensate. Mechanical misalignment / crud / lack of lube make the problem worse and less acceleration makes it much better; fix both of those problems and it'll be as good as you can get.

Changing anything else is a diversion ...
Man thanks for all of that, your insight is very helpful! I am totally in agreement that this is the problem and your solution is what I need to do. I know a lot of people use these heavier plates and I haven't seen any complaints so I'm guessing it's the newer black z motor on my rev.E that may be having issues with the extra weight when it comes to homing.

I have zero idea of what I am doing when it comes to firmware adjustments and such. Can you recommend where I should look to make myself knowledgeable regarding the firmware?

User avatar
ednisley
Posts: 1188
Joined: Fri Apr 11, 2014 5:34 pm
Location: Halfway up the Hudson
Contact:

Re: incorrect z homing behavior

Post by ednisley » Sat Dec 03, 2016 1:33 am

SIERRA086 wrote:guessing it's the newer black z motor
Remember: Hell hath no fury like that of an unjustified assumption.

The new motors have 1000-ish step/mm, so they must turn 2.5 times faster to move the Z axis at a given speed than the older motors with 400 step/mm. That means they're accelerating longer to reach that higher speed and, if either the acceleration or speed calls for more torque than they can provide, that's when they stall. On the other hand, the increased number of steps means they have a finer pitch leadscrew, which reduces the torque required to move the platform.
make myself knowledgeable regarding the firmware
The Official Guide should get you started:
http://makergear.wikidot.com/m2-firmware

I think Jules has a guide around here somewhere, too.

Protip: add your initials (or whatever) to the STRING_CONFIG_H_AUTHOR value, so you know for sure which firmware you're using!

Before changing anything else, compile & load the stock firmware (with that modified string) into the controller to demonstrate that you know how to do it and that the whole process leaves you with a functional printer. Test the Z-axis homing to see if it continues to fail; if it doesn't, then you're done.

if it still fails as before, you now have the right firmware and know how to reload it, so you can proceed.

The "Stock Configuration.h Values" section in the Guide discusses the acceleration parameters, although you want to leave the X and Y values alone for now.

You could reduce the Z axis value in DEFAULT_MAX_ACCELERATION from 30 to 3, but, now that I look at it, they've dramatically increased the homing velocity. Start by reducing that, instead, because that's most likely what's causing the problem.

Change the Z-axis homing speed in HOMING_FEEDRATE from 15*60 to 3*60, save the file, compile & stuff into the controller.

Test the results with a much slower homing speed. If it works, you can increase the speed by factors of 2 until it fails, then back off by a factor of 2. Frankly, even at a nose-pickin' speed you'll spend so little of your life waiting for the printer to home its Z axis that maybe you won't care.

If it doesn't work, leave the homing speed at 3*60, change the DEFAULT_MAX_ACCELERATION value from 30 to 3, work your way upward by factors of 2 until it stalls again, then back off by a factor of 2.

There are plenty of ways to fall off the rails while doing that, but you really can't brick the controller or wreck your printer, so take it slow and make good notes as you go...

SIERRA086
Posts: 29
Joined: Mon Oct 03, 2016 1:36 pm

Re: incorrect z homing behavior

Post by SIERRA086 » Sat Dec 03, 2016 4:10 am

Thank you again for taking the time to make this all nice and clear. You would think I would learn my lesson about making baseless assumptions but apparently that's a separate issue of mine right now. I plan to find time this weekend to play with the firmware and try out your suggestions.

User avatar
ednisley
Posts: 1188
Joined: Fri Apr 11, 2014 5:34 pm
Location: Halfway up the Hudson
Contact:

Re: incorrect z homing behavior

Post by ednisley » Sun Dec 04, 2016 3:44 pm

SIERRA086 wrote:a separate issue of mine right now
The troubleshooting checklist over my electronics bench includes two key points: "Check the plug" and "Stop thinking and look".

If past experience is any guide, the one thing I know isn't relevant ("Yes, it's plugged in, dammit!") will be the cause. [sigh]

Debugging any problem requires methodically testing all the possible causes, including ones I'm sure obviously don't matter or can't happen. After a while, you'll know what's behind most of the problems, so you can start checking the most likely causes first, but careful tests always outweigh educated guesses...

SIERRA086
Posts: 29
Joined: Mon Oct 03, 2016 1:36 pm

Re: incorrect z homing behavior

Post by SIERRA086 » Mon Dec 05, 2016 1:44 am

I like your reasoning here! I feel really stupid to admit this after this thread going on for far too long but before performing surgery on my firmware I decided totally throw out my s3d process profiles and start over with s3d. I said to myself well maybe since s3d has been generating all this gcode that is causing problems with the starting of a print I should start fresh and see what happens. Oh by the way the 'issue' was still happening with my glass bed reinstalled.

After starting fresh in s3d I NO LONGER HAVE THE PROBLEM!!! Here's what it was: I forgot that I had downloaded someone else's profiles for s3d and had been using them as a base for the past month - right when this issue arose. I now recreated my profiles using the default makergear profile as a base and the M2 homes like a dream even with my mic6 plate. So even though I thought I had the proper setup, it turns out I didn't.

I want to thank all of you that replied to this thread trying to assist me.

Post Reply