Marlin118 ABL G29 Help Needed

I am running a AnetA8 with BLTOUCH,
AUTO_BED_LEVELING_BILINEAR
3 x 3 grid (9 points)



I recently upgraded to Marlin 117 & 118, Prior to 117 I didnt have this issue,


When i do G29, during probing the machine will move Z fast for a quick second, stop, move at the normal z probing speed and probe a point,

Its as if the machine thinks the bed is out of level and further down on the right side as seems to do it more on that side, and somehow it seems to remember it as when I do G29, it probs at the normal speed on the front left,
Middle will Move z fast for like a micro second, stop, then home normal and so on,

I have tried doing G29 and afterwoods saving it with M500, but always seems to go funny again anytime i do a G28,

I have also changed
#define Z_CLEARANCE_DEPLOY_PROBE 3 // Z Clearance for Deploy/Stow
#define Z_CLEARANCE_BETWEEN_PROBES 3 // Z Clearance between probe points
To 3 (Was 5) to see if the print thinks it was above it will fast forward down to a level and then probe from there,
Although this is having the probe closer it still seems to be doing it,

The machine seems to be fine but i believe it may be slightly varying the G29 results as the speed and stop starting may not be too precise and with my G29 i can get a .100 diffence in values at times,




Any ideas??

Ben

Config Files Below

Configuration.h
Configuration_adv.h

Also am i using the correct bed leveling method (ABL)

What is UBL and is it for use with probes, which should i be using?

UBL is a super set of all the previous bed leveling technologies. It assumes an LCD Panel and a Z-Probe but it can be used without those.

I'm not going to say you should turn it on just because you would have to turn off the other bed leveling system you are using. But if you turn it on, I'll help you get it configured for your machine.
It is a good system and it works well...

Edited 1 time(s). Last edit at 02/03/2018 09:46PM by Roxy.

I hope I'm not trampling on anyone here, but I could use an assist as well. I am trying to get UBL working with 1.1.8 on my CR-10. My first problem was overcoming the problem of the filament runout sensor being always triggered. That was strangely circumvented by reducing the retraction in my slicer for some reason. Anyway, I have reached the point where I have completed the G29 P1 command to generate a mesh. When viewing the mesh, there is one value that is encased in brackets. I have not seen that documented anywhere, so why would that one value be like that?
Continuing on, I save the mesh into slot 1, set the fade height, activate it, and re-store it into EEPROM with the M500. Next, I go into the machine settings for my slicer (currently Cura 3.2-beta) and comment the G29 command in the machines start code. I did not run the test print yet, but I certainly will the next time I can play with the machine. But when I started a print, which started with a square about 4" wide, the levelling was obviously poor at best. Some parts of the skirt were crushed so badly that there was no filament on the build surface, some of it looked "ok", and some of it the nozzle was so high it would not stick to the bed. Any suggestions other than the test print which I can hopefully do today?

Thanks,

Wayne

EDIT: I reloaded 1.1.8 with UBL and am trying to run G26 K, but it doesn't take into account the Z-Offset and is just extruding filament about 3mm above the bed. Hmmm.

Edited 1 time(s). Last edit at 02/04/2018 03:35PM by xeddog.

I think I would finally have everything for UBL configured and working properly EXCEPT for the darn filament runout sensor. I finally got my mesh all edited so I get a good test pattern (three in a row even). But when I try to print anything, the runout sensor is constantly triggered.

Quote
xeddog
But when I try to print anything, the runout sensor is constantly triggered.

It sounds like you have the logic inverted. You might want to try turning off the filament run out sensor to verify it works without it. Because if it does... I think you have it inverted.

Edited 1 time(s). Last edit at 02/05/2018 10:50PM by Roxy.

OK, I got the problem circumvented with the help of someone on the Facebook CR-10 forum. I had to edit pins.ramps.h and change the value for one of the pins like so: #define FIL_RUNOUT_PIN 2. The "2" should have specified "4".

This should be corrected in a bug fix release whenever that happens.

Wayne

Correct what??? It already is set to pin 4.

[github.com]
and
[github.com]

// define digital pin 4 for the filament runout sensor. Use the RAMPS 1.4 digital input 4 on the servos connector
#ifndef FIL_RUNOUT_PIN
#define FIL_RUNOUT_PIN 4
#endif