Auto calibration not adjusting anything?
-
Has anyone run a Auto calibration and nothing was set? there is no response either in the console?
If i run a M665 or M666 nothing has changed? its always what i set in config.g
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.19 (2017-08-14)
WiFi Server Version: 1.19
Web Interface Version: 1.19( very confused)
Please point me to the correct thread if its already been discussed.
Thanks!!
~Russ
-
Just to be clear: you run auto calibration, then you send M665 with no parameters to see the new parameters and they are exactly the same as the old ones. In the Console tab of DWC there is neither an error message nor a success message. Correct?
Please post your bed.g file.
-
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
-
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.
-
Did you delete the deployprobe and retractprobe.g folders?
-
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
-
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
-
@Russ:
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ā¦
-
@Russ:
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!!
-
ok i will try that when i get homeā¦ Thanks for the help guys. so strange...
report back when its done!
~Russ
-
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
-
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
-
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.
-
I think if the majority of users do not need the feature then it should be opt-in rather than opt-out.
-
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
-
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.
-
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 cardI 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.
-
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.
-
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 -
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