Please Help - Senior Moment Strikes

[Roxy]

Yes... That is true! BL-Touch is going to be adding a new mode to the probe. If you set the servo angle at 60 degrees, it will put out the status much more like a micro-switch does. It won't put out a 5ms pulse when set at 60 degrees. I wish I had a new version of the probe!!!!

[uncle_bob]

Hi

Having spent the last 8 hours looking at just how "interesting" the output of he BLTouch is at the moment ... they can't make it any worse. I'm struggling to get it below 0.1 mm on spread over 50 repeats. Repeatability that is at >1/2 my normal layer height simply isn't going to cut it. With std deviations at 0.04, simply getting to 0.1 spread is unlikely .... If the 0.005 one sigma in their ads is correct, I'm doing something very wrong.

Trying to dig out just how to turn off the "alarm" on the BL from inside Marlin right now ... so much fun

Bob

[ex-egll]

Thanks Roxy, that's pretty much what I am doing now, at least it will be a learning experience!!

[uncle_bob]

Yes... That is true! BL-Touch is going to be adding a new mode to the probe. If you set the servo angle at 60 degrees, it will put out the status much more like a micro-switch does. It won't put out a 5ms pulse when set at 60 degrees. I wish I had a new version of the probe!!!!

Hi

So as I understand the thread over on git hub, when the steps go out past 2 ms, bad things happen in terms of catching the 5 ms wide pulse. The MakerFarm's are 4000 steps per mm on the Z axis. At 500 steps / second that would be 1/8 mm per second or roughly 5 mm / minute. My default Z feed is 2 mm / s so it's in the "ok" region. My data before was a default / 10 so 0.2 mm/s. That seemed to work fine on faults. It was junk on spread and one sigma.

Using the above data, to be out around 0.05 mm at 0.2 mm/s your timing would have to be off by 250 ms. If things are sampled at faster than 2 ms, that's a lot of time.

I kinda doubt my one sigma is from timing issues / the machine running to fast. You could trigger the data with a relay and do better than what I'm seeing.

====edit

If you watch the probe long enough as it cycles, you can catch "late" pickup events. The LED "blinks" slightly as it activates. The interesting point is that they do *not* correlate to min or max reading events. The data is still in there with the rest of it.

Contrary to all prior experience, the problem does *not* go away when DEBUG_ALL is invoked. Crazy stuff . So far, it's really hard to see how this is software related.

Off to butcher some poor helpless Marlin functions ....

==== edit

Put a median filter into the probe routine. Running with a fast probe speed (= default on the Pegasus) it improves things by ... surprise! ... square root of the samples (almost). On M48 P40 V4, the standard deviation goes from about 0.030 to about 0.015. With 5 samples that's almost right. There is something else in there other than just 1/F (flicker) noise.

Bob

[ex-egll]

Progress is being made!. Now using 1.10 RC7, pretty much everything is up and running and ready for fine tuning with one exception.

During ABL the head will move into position, servo drops down, probing is done (twice 1 fast 1 slow), head moves to next position BUT it does not raise the Z-Axis. As the servo si still down (as I believe it should be), the probe switch drags across the bed.

I have #define Z_PROBE_TRAVEL_HEIGHT 5 is there anything else that needs setting? I must admit I am going a little cross eyed reading through the config files.

Thanks

[uncle_bob]

Progress is being made!. Now using 1.10 RC7, pretty much everything is up and running and ready for fine tuning with one exception.

During ABL the head will move into position, servo drops down, probing is done (twice 1 fast 1 slow), head moves to next position BUT it does not raise the Z-Axis. As the servo si still down (as I believe it should be), the probe switch drags across the bed.

I have #define Z_PROBE_TRAVEL_HEIGHT 5 is there anything else that needs setting? I must admit I am going a little cross eyed reading through the config files.

Thanks

Hi

Switch over to RC-Bugfix. If you already have the configs for RC7, it should be a fairly quick change. There were a bunch of fixes for the BLTouch made about 10 days ago.

Bob

[ex-egll]

Hi Bob,

I switched over to RC-Bugfix and ran into problems compiling. With NO modifications to any of the files it compiles OK, but to get the LCD working I need to un-comment the following in Configuration.h

Line 1101 #define DOGLCD // Full graphics display

I can still compile after this.

Next un-comment

Line 1253 #define REPRAP_DISCOUNT_SMART_CONTROLLER

Now the compile fails with:

In file included from sketch\ultralcd.cpp:56:0:

ultralcd_impl_DOGM.h:183: error: 'DOGLCD_CS' was not declared in this scope
U8GLIB_DOGM128_2X u8g(DOGLCD_CS, DOGLCD_A0); // HW-SPI Com: CS, A0 // 4 stripes
.................................................. ..............^
ultralcd_impl_DOGM.h:183: error: 'DOGLCD_A0' was not declared in this scope

U8GLIB_DOGM128_2X u8g(DOGLCD_CS, DOGLCD_A0); // HW-SPI Com: CS, A0 // 4 stripes
.............................................^
exit status 1
'DOGLCD_CS' was not declared in this scope

Unfortunately beyond my expertise to sort that out.

Barry

[uncle_bob]

Hi

At least my (possibly incomplete) understanding is that displays are an either / or sort of thing. You get to pick one of them. I do not have the DOGLCD define uncommented and it compiles fine.

Bob

[ex-egll]

So does mine!!!

I guess I read the Configuration.h comments as:

Select either a Graphics or Text LCD at line 1100/1101

Then select the specific display later on, in my case line 1253.

One more obstacle overcome, luckily I have nothing that needs printing right now so I'll just play with the code.

Thanks for your help Bob

Barry

[ex-egll]

Rejoiced a little to quickly above...... it compiled OK but there was no display on the LCD!!!

OK, lets try to summarise progress (or lack thereof) to date with respect to LCD issues

Using Marlin 1.1.0-RC7

This will compile and work with:
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER line 1142
regardless of whether
#define DOGLCD line 976 is commented out or not

Using RC-7 Bugfix or RC-8

Will not compile with both
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER line 1253 AND
#define DOGLCD line 1101

Gives following errors
In file included from sketch\ultralcd.cpp:56:0:
ultralcd_impl_DOGM.h:183: error: 'DOGLCD_CS' was not declared in this scope

U8GLIB_DOGM128_2X u8g(DOGLCD_CS, DOGLCD_A0); // HW-SPI Com: CS, A0 // 4 stripes
.................................................. ...............^
ultralcd_impl_DOGM.h:183: error: 'DOGLCD_A0' was not declared in this scope

U8GLIB_DOGM128_2X u8g(DOGLCD_CS, DOGLCD_A0); // HW-SPI Com: CS, A0 // 4 stripes
.............................................^
exit status 1
'DOGLCD_CS' was not declared in this scope

Programme will compile with either option if the other is commented out,BUT only provides a blank screen.

IF I remove U8glib from the system then the compilation with #define DOGLCD fails, complaining of no U8glib, however compiling with #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER give no errors at all, which suggests that U8glib is not being used.
Which would mean no display.

I don't know whether the above is of any use to anyone with a better knowledge of Marlin than me?


Barry