Hyperfine bed leveling?  

Re: Hyperfine bed leveling?

I increased my max bed tuning to 500 and its getting closer but still not enough.

Cory

This is the point where the cables connect. There may be some interference by the cables in the probe's response. Can you check the thermistor cable underneath; possibly re-route it away from the probing point?

Peter

Re: Hyperfine bed leveling?

OK, this is getting interesting. It would be good to know what values people are using for their correction.

I also have 2 Prusa's but have only done this on one so far. Here is my values...

G80 A-125 B-35 C55 D55 E35 F-20 G-200 H-115

Re: Hyperfine bed leveling?

I increased my max bed tuning to 500 and its getting closer but still not enough.

Cory

This is the point where the cables connect. There may be some interference by the cables in the probe's response. Can you check the thermistor cable underneath; possibly re-route it away from the probing point?

Peter

Well Peter, YOU ARE A GENIUS! Moving the wire completely solved the problem. Still needs a higher adjustment then most but roughly -250 now. Guessing the conductivity or electricity of wire throws off that spot. They should put that in the manual.

Anyone else having this issue, just tape the wire away from that spot and rerun Z calibration.

Re: Hyperfine bed leveling?

Quick question, would seeing the printed squares on either end and use that Z live adjustment variable be accurate as opposed to using the pinda probe to provide the info back by first issuing the G80 command and getting the interpolated Z values via the G81 command?

Not sure if that makes sense my question, in laymen terms use the Pinda probe to get actual value ? If that is at all possible.

Re: Hyperfine bed leveling?

Quick question, would seeing the printed squares on either end and use that Z live adjustment variable be accurate as opposed to using the pinda probe to provide the info back by first issuing the G80 command and getting the interpolated Z values via the G81 command?

Not sure if that makes sense my question, in laymen terms use the Pinda probe to get actual value ? If that is at all possible.

The actual value is a figure that is determined by the response of the probe.

From what I can tell, this is simply correcting the probe response at different points. Basically it seems that the probe is less responsive on the right hand side of the bed (where it is close to the frame/PSU) and much more responsive at the left rear (where the heat bed connectors are).

But different beds also generate different probe responses; it looks as though there are several factors which cause these differences and not simply bed design/manufacture.

Peter

Re: Hyperfine bed leveling?

@PJR If I understood correctly from your post having read it several times, you are effectively force inputting the correct 9 correction values by having the Gcode in the printer startup script which you have calculated after various test prints of the 9 squares.

After the editing of the firmware it is effectively making room in the Firmware variables to be ready to accept this new 9 points you calculated from the startup gcode script.

Correct?

Re: Hyperfine bed leveling?

@PJR Peter, I just had one of those epiphany moments 😀

After modifying the firmware per your indications, I kept having problems with the rear left point.
No matter how much I corrected it, Z offset was always too high.
After inserting a few debug prints in the code, I found out the correction level for the rear left point was always +80.
Why? 😕 Why should point G always revert to 80? Wait... G = 80... G80 !! ❗ 💡


for (uint8_t i = 0; i < 8; ++i) {
unsigned char codes[8] = { 'A', 'B', 'C', 'D' , 'E' , 'F', 'G', 'H'};
long correction = 0;
if (code_seen(codes[i]))
correction = code_value_long();
else
continue;


See?
code_seen() parses the whole GCODE command line for parameters, and finds G80 right there in front !!

After changing to
unsigned char codes[8] = { 'A', 'B', 'C', 'D' , 'E' , 'F', 'H', I'};


Now everything works as it should.
Thanks for your your brilliant idea !!

Re: Hyperfine bed leveling?

@alsand I was working on that very thing right before you posted and was wondering the same thing it should be 9 but i see only 8 letters, I was like am I missing something or I just cant read for some reason.

9 squares why only 8 letters....

Edited, never mind thinking too much just realized we are not talking the same language. 😆

Re: Hyperfine bed leveling?

@PJR Peter, I just had one of those epiphany moments 😀

After modifying the firmware per your indications, I kept having problems with the rear left point.
No matter how much I corrected it, Z offset was always too high.
After inserting a few debug prints in the code, I found out the correction level for the rear left point was always +80.
Why? 😕 Why should point G always revert to 80? Wait... G = 80... G80 !! ❗ 💡


for (uint8_t i = 0; i < 8; ++i) {
unsigned char codes[8] = { 'A', 'B', 'C', 'D' , 'E' , 'F', 'G', 'H'};
long correction = 0;
if (code_seen(codes[i]))
correction = code_value_long();
else
continue;


See?
code_seen() parses the whole GCODE command line for parameters, and finds G80 right there in front !!

After changing to
unsigned char codes[8] = { 'A', 'B', 'C', 'D' , 'E' , 'F', 'H', I'};


Now everything works as it should.
Thanks for your your brilliant idea !!

I am going to try this. Still having problems with the back left point after moving the wire. Its variable but setting is significantly different. I'll try this and see if it measures out better

Thanks for figuring this out!!!

Re: Hyperfine bed leveling?

@PJR Peter, I just had one of those epiphany moments 😀

Many thanks for correcting my error! Brilliant catch. I had checked to ensure A through H were not being used, but hadn't taken into account the G80.

Peter

Re: Hyperfine bed leveling?

@PJR If I understood correctly from your post having read it several times...

OK, here's the explanation:

In the default firmware, we can use G80 with L, R, F and B as parameters to correct the probe response for the Left, Right, Front and Back. But these corrections affect 6 of the probing points, the row/column to which they refer by 100% of the value entered and the neighbouring row/column towards the centre by 50% of the value entered.

So, if you need to lower the nozzle along the front row by 50 microns, you would use G80 F-50. However this will change all the 3 front points by -50 and all the centre points by -25.

I could not get this to work, so I amended the firmware to allow adjustment of the 8 outside points, with the centre point being adjusted with the "Live Z Adjust" only. So the procedure is this:

Print a centre test square and set Live Z Adjust to get a good print.
Print the 8 outside squares and use A though H to get good prints at all 8 individually.

Hope this explains it better.

Peter

Re: Hyperfine bed leveling?

congrats !

Re: Hyperfine bed leveling?

congrats !

Oh Bugwarts! A triple-deca-nelson!

Thanks anyway!

Peter

Re: Hyperfine bed leveling?

After modifying the firmware per your indications, I kept having problems with the rear left point.
...
unsigned char codes[8] = { 'A', 'B', 'C', 'D' , 'E' , 'F', 'H', I'};

Now everything works as it should.
Thanks for your your brilliant idea !!

OK so what do you think about using lower case "a" through "h"? I would very much prefer the letters to be consecutive...

Looking forward to your/everybody's input on this...

Peter

Re: Hyperfine bed leveling?

@PJR thanx for the input just a note my pinda was set at 0.75 and Z level is at -0.875um I have balance of 125 to play around with if any of those squares require more then 125 I would need to readjust the height of the Pinda.

As for the lower case have time to kill and hash it out later tomorrow for sure..

Re: Hyperfine bed leveling?

@PJR Peter, I just had one of those epiphany moments 😀

After modifying the firmware per your indications, I kept having problems with the rear left point.
No matter how much I corrected it, Z offset was always too high.
After inserting a few debug prints in the code, I found out the correction level for the rear left point was always +80.
Why? 😕 Why should point G always revert to 80? Wait... G = 80... G80 !! ❗ 💡


for (uint8_t i = 0; i < 8; ++i) {
unsigned char codes[8] = { 'A', 'B', 'C', 'D' , 'E' , 'F', 'G', 'H'};
long correction = 0;
if (code_seen(codes[i]))
correction = code_value_long();
else
continue;


See?
code_seen() parses the whole GCODE command line for parameters, and finds G80 right there in front !!

After changing to
unsigned char codes[8] = { 'A', 'B', 'C', 'D' , 'E' , 'F', 'H', I'};


Now everything works as it should.
Thanks for your your brilliant idea !!

You still need the extra comma in front of "I" correct?

Re: Hyperfine bed leveling?

@PJR thanx for the input just a note my pinda was set at 0.75 and Z level is at -0.875um I have balance of 125 to play around with if any of those squares require more then 125 I would need to readjust the height of the Pinda.

As for the lower case have time to kill and hash it out later tomorrow for sure..

I would suggest that it's probably worthwhile raising the probe a little in any event. It may have a tendency to catch os the occasional curling parts.

I set my probe as high as possible so that the nozzle just touches the bed at one point during 9-point calibration and then lower it about 100 microns from that position. Live Z is around -150.

And thank you for your input on this!

Peter

Re: Hyperfine bed leveling?

You still need the extra comma in front of "I" correct?

Yes, well spotted. Single quote; should have been:

{ 'A', 'B', 'C', 'D' , 'E' , 'F', 'H', 'I'}

Many thanks

Peter

Re: Hyperfine bed leveling?

This seems to be working well. Although I am noticing a big change since moving the wire. I think things have been kinda variable if the original G identifier wasn't working since it got better and worse variably. I tried purposely making worse and better and worked each time!

They should definitely change the built in code to support this and input in menu!

Re: Hyperfine bed leveling?

hey should definitely change the built in code to support this and input in menu!

Cory, there is a big problem in making a change like this in firmware and that is the many thousands of users for whom the current method works.

This would be a rather major change and It is not a simple matter of releasing amended code. The devs are aware of this but I think it may be a long time before the standard firmware contains this method.

Peter