Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

G29 responds 'ok' but there is no movement. #5968

Closed
okkman opened this issue Mar 5, 2017 · 8 comments
Closed

G29 responds 'ok' but there is no movement. #5968

okkman opened this issue Mar 5, 2017 · 8 comments

Comments

@okkman
Copy link

okkman commented Mar 5, 2017

I'm certain I'm doing something stupid but I can't figure out what. I've read through a dozen threads with similar problems but have not found a fix. Setup is 1.1.0 RC8 running on Ramps 1.4 on an i3 clone. I have an inductive sensor and it seems to be working, M119 shows expected behavior from sensor and end stops. The printer homes fine and responds as expected to G28, but when I try G29 it responds 'ok' and doesn't move at all. I'm at a loss! been unable to print successfully for over a month now and very frustrated. I appreciate any help, but I'm not a programmer and way over my head here.

attached Configuration.h, Configuration_adv.h
Configfiles.zip

@brainscan
Copy link

Not sure if this is the problem but if you have an inductive probe you need to add a - before the z offset so it reads -4 rather than 4. Not sure if that's messing with software endstops or not. I'll keep looking through to see if anything else jumps out at me and hopefully other (smarter) people are looking at it too.

@ghost
Copy link

ghost commented Mar 5, 2017

Please download, setup, and run RCBugFix.

@Bob-the-Kuhn
Copy link
Contributor

With your config Z_MIN_PROBE_ENDSTOP_INVERTING and Z_MIN_ENDSTOP_INVERTING should be the same. I expect that M119 always says the probe is triggered.

#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define Z_MIN_PROBE_ENDSTOP_INVERTING false
#define Z_MIN_ENDSTOP_INVERTING true

If they're really different then you need to separate the two and define a Z_MIN_PROBE_PIN.

@okkman
Copy link
Author

okkman commented Mar 6, 2017

@brainscan I failed to mention that I made the change to 4 from -4 in my last upload due to something I had read in another post. It didn't seem to change anything but I will change it back.

@Bob-the-Kuhn my M119 works correctly with these settings which I confirmed by checking it frequently. On my last upload I moved the probe further from the bed before starting to eliminate early triggering from the equation (also a solution I found online) but again, it made no difference. Bear in mind that I can home all axes reliably and do so before sending G29.

@ghost
Copy link

ghost commented Mar 6, 2017

PR #5837 fixed broken homing. It was applied to RCBugFix. You can see if these changes are in yours. If not, apply them and see if that helps.

@Bob-the-Kuhn
Copy link
Contributor

Bob-the-Kuhn commented Mar 6, 2017

You need to switch to the Configuration.h & Configuration_adv.h files that came with RC8.

The auto leveling feature has changed since your Configuration.h file was created. Essentially you're telling the software to do auto bed leveling but not specifying which method to use.

The easiest way to switch is to get Notepad++ and it's compare plugin. It has a nice side by side difference report.

You'll find a LARGE number of differences. You can ignore most of them. Just make sure you copy your machine specific items over. You'll also need to pick one of the auto bed leveling systems.

@okkman
Copy link
Author

okkman commented Mar 7, 2017

Thanks @Bob-the-Kuhn, you were absolutely right! What I didn't realize when using those files from another user in the printer group with the same machine, was that his config was from a previous version of Marlin. Lesson learned about grabbing files from someone else's setup. Other really strange behavior this caused was random printer stops after only a few layers, and occasionally wild movements outside the boundaries of the printer. Marking this closed.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants