Results 31 to 40 of 112
Thread: Auto Bed Levelling Glitches
-
11-07-2014, 05:13 PM #31
- Join Date
- Jul 2014
- Location
- Ontario, Canada
- Posts
- 257
Well here is my quick recap showing what happens with g28. I didn't include a g29 in it, but I'm sure you know what happens by now. Aside from this behavior, my z height is way off. When the print starts, the head is about 12mm off the bed. I re did the measurements and had an offset of roughly 8.60, but still it was way put of whack. I will try a few little things and see if it fixes it. I wonder if the g28 glitch had anything to do with it...
https://www.youtube.com/watch?v=Yi5dZ453f4Y
https://www.youtube.com/watch?v=krgCB0PZdtw
Ryan
-
11-07-2014, 05:34 PM #32
- Join Date
- Jul 2014
- Location
- Eastern Colorado
- Posts
- 536
I had the problem of my print head being too high off the bed after a G28, too. I would do a G28, then a G1 Z0, then manually in Pronterface lower the head until the nozzle just gripped a piece of paper. This showed me it was 4mm too high. To fix it, I modified this line in marilin_main.cpp:
Code:#ifdef ENABLE_AUTO_BED_LEVELING if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) { current_position[Z_AXIS] += zprobe_zoffset; //Add Z_Probe offset (the distance is negative)
Code:#ifdef ENABLE_AUTO_BED_LEVELING if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) { current_position[Z_AXIS] += zprobe_zoffset+4; //Add Z_Probe offset (the distance is negative)
-
11-07-2014, 06:39 PM #33
Wow... That is really weird. One more question before we dig in. If you reset the printer with the nozzle somewhere in the middle of the bed: What happens if you do a M114 prior to do the first G28? The G28 should home regardless , but it is very strange that it doesn't head out to the center of the bed after the home.
The G28 code is complicated because of all the different conditional code in there. But I see where we need to put the debug code. We should be able to get a handle on this pretty quickly. I'll try to get a version of your Marlin_main.cpp posted with debug code in it in the morning. And maybe we can figure out where it is making the bad decisions. Probably, it will take a couple of iterations because we will want to put debug code in the various paths to make sure it is going the right places. But then, with that information, we will need more detailed debug information and have to add some extra print outs.
Incidentally, the code paths do vary significantly depending upon whether you home just one axis or all of them. So even though it should behave the same, it is understandable that you see different results.Last edited by Roxy; 11-07-2014 at 07:44 PM.
-
11-07-2014, 07:31 PM #34
- Join Date
- Jul 2014
- Location
- Ontario, Canada
- Posts
- 257
Thank you both for helping, I can't tell you how much I appreciate it!
I ran a M114 before anything else, the head in the middle of the bed, it returned 0,0,0. The first G28 then returned X93 and Y131 (when the head was actually 0,0 and then the second G28 which moves to the center of the bed, and yet still has thru same values.... weird....
-
11-07-2014, 07:53 PM #35
- Join Date
- Jul 2014
- Location
- Eastern Colorado
- Posts
- 536
Question for Ryan, what happens if you run Auto Home from the LCD?
-
11-07-2014, 08:23 PM #36
- Join Date
- Jul 2014
- Location
- Ontario, Canada
- Posts
- 257
Hmm.... so is it something in my Repetier then?... auto homing from the LCD panel works perfectly fine. Goes to 0,0 then returns to Centre and probes the 7
I haven't changed any settings on RH in ages... it's printed perfectly for my MakerFarm, and Printrbot too....
-
11-07-2014, 08:30 PM #37
- Join Date
- Jul 2014
- Location
- Eastern Colorado
- Posts
- 536
I have no experience with Repetier, but I thought it'd be good to find a way to remove it from the chain, to see if it may be a contributing factor.
-
11-07-2014, 09:52 PM #38
I doubt this is being caused by Repetier... But I don't use it. Would you mind switching to PronterFace until we get this resolved? I have never seen this kind of weird behavior and it might be best to remove any variable we can. With that said... Once we start running the debugging version of the code, we are going to be able to figure out what is causing the bad code paths to be taken.
-
11-08-2014, 12:53 AM #39
- Join Date
- Jun 2014
- Posts
- 74
I'm not experienced enough to really be of any help here, but thought I would mention I stopped using Repetier because of many inconsistencies I had similar to this. Since I switched to Pronterface I have not had the same types of issues. So I agree it would be very interesting to see if a different control software shows different results. I really like the UI of Repetier, but I just couldn't work through the issues. It looks to me that either Repetier or the hardware buffer is holding and reporting old values.
-
11-08-2014, 07:58 AM #40
New member with print issue
Yesterday, 08:57 AM in Tips, Tricks and Tech Help