Closed alitai closed 8 years ago
`
Hi @alitai You should post your entire Configuration.h
so we can see your movement limits, endstop configuration, etc.
It will also help if you enable DEBUG_LEVELING_FEATURE
. Then you can use M111 S32
to enable extra logging for leveling. Please post the output of your log when you do G29
.
@thinkyhead - I've posted the entire configuration.h above. I've set the debug and will post it as soon as I can.
One point I'd like to add is that when I disable the Auto Bed Leveling Feature (by quoting the line #define AUTO_BED_LEVELING_FEATURE) - the print works great, centered around the x0 y0 z0 point in the middle of the bed.
I've been running the points as they appear in the log - they are indeed spread evenly on the bed.
I don't know why the actual G29 shifts so they run in a single quadrant. And at a slant...
For a test set your Z_RAISE_BETWEEN_PROBINGS
to a very high value. 0,0 is usually not a point to probe but the place to go before the first probing. If you touch the bed here the tower coordinate system is messed up.
Alternately your MANUAL_Z_HOME_POS
could be too high.
@Blue-Marlin - Thank you - I changed Z_RAISE_BETWEEN_PROBINGS from 5 to 25. While jumping higher between probes - It still touches the x0 y0 z0 point, and then moves to the next point in the negative (-) X direction.
Indeed it looks as if the coordinate system is messed up - but when I printed some items (without G29) and they printed well - and centered. Can the coordinate system be messed up only for ABL?
@Blue-Marlin - If the MANUAL_Z_HOME_POS would be too high then issuing a G0 Y0 X0 Z0 would touch the bed? It doesn't. I calibrated the printer so the nozzle is paper thickness from the glass bed.
Not for ABL. Because ABL touches 0,0 unplanned. However - the code in this area changed last night. Please try the newest RCBugFix.
I did install the latest today (about 2 hours ago). I'll see if there were any new commits since I last downloaded.
Interesting about having a different coordinates for ABL. How does one go about zeroing XY&Z for ABL?
Try setting AUTO_BED_LEVELING_GRID_POINTS
to a more sane value like 3 or 4.
There's no need to sample 81 points on the bed!
Can the coordinate system be messed up only for ABL?
ABL takes a given idealized XYZ from your GCode and modifies the XYZ to produce a corrected position based on the tilt of the bed. Since ABL uses only a single tilt across the whole bed, it's important that the sampled points be accurate and that there be very little irregularity in the bed when you probe. Too much irregularity will give strange results.
@thinkyhead He has a delta. Here ABL is more like Mesh-Leveling. No matrix!
Ah… I'm not too familiar with the difference in Delta leveling.
@thinkyhead The setting is at 9 points #define AUTO_BED_LEVELING_GRID_POINTS 9. It is similar to what I had before.
@Blue-Marlin ABL worked well on RC6 (the print itself didn't, though) and on a previous Marlin firmware I have been using for more than a year. The Bed is Glass, is rather flat, and the endstops are finely adjusted using a screws so I have a rather well calibrated system (if I say so myself - a 50mm test jig comes out at 50.08mm and symmetric). I use Hiwin rails which make the 1515 rather stable.
Since ABL worked on RC6 - I wonder what had changed since RC6?
So I made a few movies of running ABL on the Bugfix version (where ABL fails) and the RC6 version (where ABL succeeds).
ABL functioning on RC6: https://vimeo.com/173734690 ABL fails on current (see below) Bugfix version: https://vimeo.com/173734695
A coincidental observation: Something during G29 is screwing up the Delta Coordinates - I stopped shooting the Bugfix movie right as it hit the GT2 belt. So to move it away from the tower I used the motor controls and discovered that the movement plane was completely off - a Y move resulted in a nearly 45 degree slant on Z. After using M28, the move was perfectly flat parallel to the bed plane.
Slanted movement after G29: https://vimeo.com/173734614 Normal movement after G28: https://vimeo.com/173734397
This was shot with an updated firmware - updated to commit 4e84c803a37d89e85e2b49aaa0747a8766344ca3 from July 7.
Would you mind posting the G29 log from 1.1.0-RC6 so I can compare it to the log from RCBugFix? Meanwhile I will look more closely at the code. We did a huge amount of cleanup on bed leveling, and somewhere in the process we clearly overlooked something.
@thinkyhead Thank you - I will do it in an hour or so when I get back.
Here is the Log of the G29 from RC6:
From the video it looks like a weird assortment of probe points. Are they all within a single quadrant of the bed, or does it probe elsewhere?
Are you using the same Configuration.h
file for RCBugFix
as you are using for RC6
, or did you modify it a bit?
So far in my examination of the G29 code nothing is jumping out as an obvious bug. I think it must be someplace in-between, maybe.
G28
before anything else and then send movement commands, does the delta go to all the right positions?G29
leveling procedure does the LCD show the correct X, Y, Z coordinates?This is making me think it would be nice to have an LCD option to cancel G29
leveling in-progress.
@alitai I've created a branch for testing where I can add more logging to figure this out. I already did a few tweaks to it, so give it a try and see if it works any differently:
https://github.com/thinkyhead/Marlin/tree/th_delta_debug_homing_leveling
I will add more logging to that if needed, and hopefully we'll figure it out quickly.
@thinkyhead
I actually tried to use the same Configuration.h. But the one I use now is different - there are quite a few differences between the RC6 and the Bugfix files - Hitachi character set was changed from Japan to Japanese; there were additional Z probe Raise parameters in RC6 that don't exist in the Bugfix, etc.
@thinkyhead So I looked at the LCD - Indeed there is a mismatch between the LCD and where the effector/hotend is. For example, it starts off at Y=-49 (which should be close to the edge of the bed) - but the effector is at Y=0.
So the first probe should be X=31 Y=-49 but it ends up being X=0 Y=0.
FWIW, the debug version does print well Printing a Flexible PLA Sink Stopper
I guess not having ABL as a crutch gets one to calibrate one's printer better... :)
So I wanted to try to isolate the problem - configuration or code. I took the RC6 configuration.h and configuration_adv.h and modified them to work on the Bugfix debug version that @thinkyhead sent.
That did not solve the problem - the probing started (incorrectly) at X0 Y0. So I guess it isn't a configuration issue.
Below are the changes that had to be done to the older (RC6) configuration.h and confiuration_adv.h to get them to compile successfully:
Configuration.h
#define CONFIGURATION_H_VERSION 010100
#define DISPLAY_CHARSET_HD44780 JAPANESE
#define FIX_MOUNTED_PROBE
#define Z_RAISE_PROBE_DEPLOY_STOW 50 // Raise to make room for the probe to deploy / stow
#define LCD_LANGUAGE en
#define XY_PROBE_SPEED 4000
Configuration_adv.h
#define CONFIGURATION_ADV_H_VERSION 010100
I also tried enabling #define BED_CENTER_AT_0_0 and disabling //#define Z_SAFE_HOMING. Didn't help.
I was thinking, if the probing was limited to a single quadrant, then maybe it was related to software endstops. But then, you would be limited in all your movements, regardless of bed leveling.
This is indeed quite a puzzle. I could use additional assistance from someone with a delta. I think @Roxy-3D has one…? I'm really stuck without a delta of my own to test with.
I can help in a couple of days. But right now, my Delta is missing one of its stepper motors. I was trying to convert my FolgerTech i3-2020 to use 3mm filament and it was skipping steps. So I wanted a higher torque stepper motor to see if that would let me use 3mm filament. I cannibalized my Delta to get a motor so I could keep going. (Unfortunately, the higher torque motor didn't fix the skipped steps.) In a few days I'll have the motor back where it belongs.
I was skipping steps with RC6 (quite a lot actually) - but bugfix version solved that.
I am stumped too. The lift in Z seems to imply the coordinate translations work as well. The LCD shows the proper coordinates. It is as if an offset is introduced in the stepper counters...
I was skipping steps with RC6 (quite a lot actually) - but bugfix version solved that.
Has anybody else been talking about stepper motors losing steps in RC-6? I know in my case it was just the extruder motor. And I also know the stepper motor wasn't strong enough to push the heavier filament through the nozzle. But for sure, we don't want this to be caused by the firmware!
@alitai Can you give a test of the probing commands outside of G29
to see that they do the right thing?
* G30 - Single Z probe, probes bed at current XY location.
* M401 - Lower Z probe if present
* M402 - Raise Z probe if present
Meanwhile I will try to figure out someplace where added logging might help reveal something.
My best guess, for the moment, is the blocking_move_to(first probe point)
from home position. In a not subdivided delta move it's obvious - all axes move in negative direction - none of the endstops can be triggered. Due to the subdividing, one of the axes might go a tiny bit upwards. Because the endstops are still triggered at home position, the first of the subdivided moves is stopped, the coordinate system gets messed up.
For a test we could ask for adding an endstop_adj
of a few mm to all axes to free the endstops before another move can happen. Or we could simply try:
G28
G91
G0 Z-10
G90
G29
@AnHardt Another change we made recently was - for deltas that had a specific (50, 100, 150) Z-before-probing value, the effector would move down to that coordinate. But now we don't move down, only up, so we might have lost that initial move. (Or, with delta and/or Z max machines, I might have made an exception and still lower to that point.) I'll have to peek at the code to remind myself. Anyway, perhaps that initial lowering is helpful.
@alitai Can you give a test of the probing commands outside of G29 to see that they do the right thing?
- G30 - Single Z probe, probes bed at current XY location.
- M401 - Lower Z probe if present
- M402 - Raise Z probe if present Meanwhile I will try to figure out someplace where added logging might help reveal something.<
So I probed at a few points outside the quadrant the ABL is stuck in such as x-35 and y-35 and it worked well. The nozzle touched the bed at the proper location - and returned properly.
For
a test we could ask for adding an endstop_adj of a few mm to all axes to free the endstops before another move can happen. Or we could simply try:
G28 G91 G0 Z-10 G90 G29<
I tried this - It doesn't solve the problem - what should I be looking for?
I hoped for a straight correct move from [0,0,z_max-x] to the first probe point in G29 with x bigger than a few 1/10mm. :-(
Did we already talk about ENDSTOPS_ONLY_FOR_HOMING
(Configuration_adv.h)? Please alter it and test again.
Tried quoting out -
//#define ENDSTOPS_ONLY_FOR_HOMING // If defined the endstops will only be used for homing
And it made no difference. :-(
Ok. Let's see what's going on. https://github.com/AnHardt/Marlin/pull/56 Not as beauty(ful) as thinkyhead could have done it, but hopefully i can see what when is going on.
@alitai Did you have a chance to test the debug code @AnHardt has provided?
@thinkyhead @AnHardt I do apologize. I am rather new on GitHub and didn't know that the AnHardt#56 was a build for me to try. I was actually looking at this thread daily for the next set of instructions. I will test this later today.
I am not sure how to use this. I tried showing the code for commit AnHardt#56 as full code and downloading it. Added it to the RCBugFix and to the AnHardt code tab download - and in both cases got a "conflicting decleration 'volatile boot_wait_for_heatup'" compiler error.
In the main AnHardt code tab - I don't see the report_current_position() calls that the #56 has...
Tried quoting out the lines that compiler was unhappy with and made it even less happy...
I guess the question is how do I find and download the code that goes with the #56 commit?
@alitai At the top, notice that the name of the branch that AnHardt#56 comes from is rep-pos-delta-G29 (https://github.com/AnHardt/Marlin/tree/rep-pos-delta-G29). Download the ZIP from there, or you can check it out with Github Desktop, if you have that installed.
@thinkyhead - Thank you - downloaded it and it worked. Posted the log and configuration.h into the AnHardt#56 message.
BTW - On a side note, the configuration.h version may need to change as CONFIGURATION_H_VERSION 010100 no longer compiles with the code. Missing some declarations.
Hi - Still working on getting the BugFix version to work. Downloaded a new RCBugFix branch today and am getting an issue with the ABL functionality. The probing starts in the center (X0 Y0) and moves to the rear right quadrant, and does so at a slant.
I am using the Zmin pin and the nozzle as a probe (with a Trinket Based FSR detector), so offsets are all '0'.
Thanks,
Assaf
Bed Leveling Configuration
``` cpp // @section bedlevel #define AUTO_BED_LEVELING_FEATURE // Delete the comment to enable (remove // at the start of the line) //#define DEBUG_LEVELING_FEATURE #if ENABLED(AUTO_BED_LEVELING_FEATURE) // There are 2 different ways to specify probing locations: // // - "grid" mode // Probe several points in a rectangular grid. // You specify the rectangle and the density of sample points. // This mode is preferred because there are more measurements. // // - "3-point" mode // Probe 3 arbitrary points on the bed (that aren't collinear) // You specify the XY coordinates of all 3 points. // Enable this to sample the bed in a grid (least squares solution). // Note: this feature generates 10KB extra code size. #define AUTO_BED_LEVELING_GRID // Deltas only support grid mode. #if ENABLED(AUTO_BED_LEVELING_GRID) // Set the rectangle in which to probe #define DELTA_PROBEABLE_RADIUS (DELTA_PRINTABLE_RADIUS - 10) #define LEFT_PROBE_BED_POSITION -(DELTA_PROBEABLE_RADIUS) #define RIGHT_PROBE_BED_POSITION DELTA_PROBEABLE_RADIUS #define FRONT_PROBE_BED_POSITION -(DELTA_PROBEABLE_RADIUS) #define BACK_PROBE_BED_POSITION DELTA_PROBEABLE_RADIUS ```