Auto calibration not adjusting anything?

Russ Gries

Thats correct David.

I'm use to there allways being a feed back in the console stating the changes and deviation etc

However nothing will post at all and there will be no change.

The G32 will post in green in the console and thats it.

No errors at all. If I run a single probe command I can get a hight feed back. So I know the probe and such is working.

Also something new to me. Is that the probe will allways probe. Then go back the the center of the bed. Then move up then go to the next point?

At some point in the past after an upgrade this started. Is that the new normal? Posibaly that's a clue that somthing is wrong?

I'll grab the bed.g in the morning (2AM) ( currently awoken from sleep by one of my little helpers its to quiet in the house to boot the printer. Got a mean server power supply fan on thst beast.)

Also its the same old bed.g as I allways used.
Also tried a new one using the wizard to genarate the code. However no help.

Thanks!!! ~Russ

dc42

It sounds as if there is no S parameter on the final G30 command in bed.g.

You could put a M117 command to print a message at the end of bed.g to make sure it is getting to the end.

number40fan

Did you delete the deployprobe and retractprobe.g folders?

Russ Gries

here is the bed.g,

i simplified it down just for testing, but the same result. no change after a G32 ( or G32 S1 Or S2…).

; Auto calibration routine for delta printers
; Before running this, you should have set up your zprobe Z offset to suit your build, in the G31 command in config.g.

M561				         ; clear any bed transform, otherwise homing may be at the wrong height
G28			                 ; home the printer
M557 R130 S50                           ; full bed probe. define a grid with the specified radius and spacing (for delta printers)results are spored in file /sys/heightmap.csv

;*** Remove the following line if your Z probe does not need to be deployed
; M98 Pdeployprobe.g			; deploy the mechanical Z probe

; The first time the mechanical probe is used after deployment, it gives slightly different results.
; So do an extra dummy probe here. The value stored gets overwritten later. You can remove this if you use an IR probe.
G30 P0 X0 Y0 Z-99999

; probing radius: 160 for full bed, but found out that 100 is good because the rest is out of the window for proper probing. 
; go here to get numbers : http://escher3d.com/pages/wizards/wizardbed.php

; bed.g file for RepRapFirmware, generated by Escher3D calculator
; 4 points, 4 factors, probing radius: 125, probe offset (17, 4)
G30 P0 X0.00 Y120.09 Z-99999 H0
G30 P1 X97.88 Y-56.51 Z-99999 H0
G30 P2 X-108.25 Y-62.50 Z-99999 H0
G30 P3 X0 Y0 Z-99999 S4

;*** Remove the following line if your Z probe does not need to be retracted
; M98 Pretractprobe.g				; retract the mechanical Z probe

G1 X0 Y0 Z150 F15000			; get the head out of the way of the bed
M117 is this working?

first thing i checked was the S parameter. i spend about 3 hrs trying all kinds of things, nothing seems to work.

very strange?

M117 added, indeed it posts!

Thanks!!!

~Russ

Russ Gries

@number40fan:

Did you delete the deployprobe and retractprobe.g folders?

those 2 "files" ( folders?) are still on the SD card. but I'm not calling them any way.

~Russ

whosrdaddy

@Russ:

@number40fan:

Did you delete the deployprobe and retractprobe.g folders?

those 2 "files" ( folders?) are still on the SD card. but I'm not calling them any way.

~Russ

Delete them and be amazed…

number40fan

@whosrdaddy:

@Russ:

@number40fan:

Did you delete the deployprobe and retractprobe.g folders?

those 2 "files" ( folders?) are still on the SD card. but I'm not calling them any way.

~Russ

Delete them and be amazed…

Yep!!

Russ Gries

ok i will try that when i get home… Thanks for the help guys. so strange...

report back when its done!

~Russ

Russ Gries

that was it… we should document that some where on the G code page ( old verse new ) i dont know I'm just glad its working

thanks guys! just when you think you know what your doing something so simple happens

~Russ

AndreS

It is documented, not yet on the G-Code page, but see here:
https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md
Scroll down to Version 1.19, the 3rd point:

Important! If you use an IR Z probe or some other type that does not need to be deployed, delete the files sys/deployprobe and sys/retractprobe.g if they exist, because they are now called automatically. You can do this in the System Files Editor of the web interface.

and some more down, this is related:

Probe deployment and retraction for G30 and G29 commands is now handled automatically. You should still include a M401 command before the first G30 command in bed.g and a M402 command after the last one, so that the probe deploys and retracts once for the entire sequence instead of once per G30 command.

Always read the update notes.

Andre

DADIY

Perhaps the contents of those files should be commented out by default as this seems to be catching out a lot of people at the moment.

DjDemonD

I think if the majority of users do not need the feature then it should be opt-in rather than opt-out.

AndreS

I think: no. Some need that files.

The solution is: Always read the update notes, if you want to update, read and pick the relevant information for your printer.

Many users are NOT doing this and are struggling with this update.
David put out all important information, but people are ignoring them. They make the update and are wondering that some things are going crazy.

Sorry that I may seem to be a little harsh, but at the moment there are many posts, that are related to: not reading update notes.

Andre

dc42

The SD cards that are shipped with current production Duets are dummy ones that do nothing. But for a long time we shipped SD cards with real sample deploy and retract sequences in those files, so a lot of users still have them.

Jarery

I have what 'seems' a similar issue.
I'm using the newest 1.19.2
Since my Probe (bltouch) requires deploy and retract I've left those files on the SD card

I run bed levelling routine
I run Bed Mesh routine
M500
I print and the first layer is a filament that is a round tube layer onto the bed when its 100mm left of the xy origin, and a completly squished flat almost dragging the bed strip when 100mm to the right of the origin.

Its as if the bed mesh info is not loading or not being used.

Any thoughts? Since mine also appears to have issues with wifi even though updated do I need to refresh from scratch ?

"Important! If you use an IR Z probe or some other type that does not need to be deployed, delete the files sys/deployprobe and sys/retractprobe.g if they exist, because they are now called automatically. You can do this in the System Files Editor of the web interface.

dc42

You can check whether the height map is being used by running M122. One of the parameters it reports is the type of bed compensation in use.

Jarery

Thanks. It wasn't Loading after a reset as shown in the M122

I guess I assumed it operated similar to the smoothie board I came from and loaded if a map was stored.
Or perhaps my levelling routing has a code to clear it and I need to reload it after bed levelling routine is run. Will check later

dc42

You can activate mesh bed compensation in two ways:

1. By running G29 S0 (or just G29) to probe then bed and generate a height map. If successful, the height map will be both saved to file (default filename is /sys/heightmap.csv) and activated.

2. By using G29 S1 to load a previously-generated height map file. Again, the default filename is /sys/heightmap.csv. You can use this command in config.g if you wish, or at the end of your homeall.g or homedelta.g file.

On the Duet, M500 is not connected with mesh bed compensation.

See https://duet3d.com/wiki/Using_mesh_bed_compensation.

HTH David