Doh - unfortuntately I am obviously so bad in text based code that i cant even upload an image
Well its still saying it did do leadscrew adjustments but it doesnt..
Plus i do not seem to be able to individually define mesh grid points instead of a pattern with a predefined spacing. If i would like to scan and display the heightmap with only 4 points for bed levelling before compensation during print, that it not possible if a have a non symmertric bed (like 200x300 as i do).
1. Your bed probing for leadscrew adjustment and your G29 bed probing appear to differ in their idea of where Z=0 is by about 0.8mm. Are you homing during the sequence at all, e.g. in the bed.g file ?
2. What happens if you run leadscrew adjustment multiple times, without homing or doing G29 in between? Does the adjustment converts to near zero?
3. The M557 mesh bed compensation allows you to specify different X and Y spacings for the grid. So you can do 4 point probing on a rectangular bed.
Hi, M557 worked, using two different s parameters for each axis is doing the trick - thanks!
I dont get leadscrew adjustments yet, with or without homing. It still says leadscrew adjustments are made when they are not - e.g. leadscrew 4 at motor 8 offset is constantly 50 µm off and not being adjusted automatically, when manualy adjustment is working by splitting the z motor definition to individual ones using M584 (meaning that i can move individual z motors so they are not under defined when only defining one z motor in config.g, correct?)
That sounds odd. If the firmware says that leadscrew adjustments have been made, then it should have sent step pulses to the motors. Are you certain it isn't adjusting them? The movements may be too small to see easily. One test you can do is to run G31 repeatedly to see if the reported corrections change.
My z-motors are arranged counterclockwise, if that matters?
It doesn't matter, as long as you list the leadscrew coordinates of the Z motors in the same order that you list the corresponding drivers numbers.
Hi again, so I crosschecked individual z-axes movements using a borrowed mitutoyo scale. Each axes can be adressed individually and moves exactly the given amount e.g 0.13 mm and so does the concerto when joined back together (within the total travel and error of the scale When I try to correct for the offsets given by the heighmap though, I have to move them axes approximately twice as much as indicated in the offsets (doing it manually). Does that indicate some possible source of error in my settings (since the steps per millimeter are defined for Z, its not necessary to define the pitch anywhere e.g., right)?
Ok, changing configuration to clockwise now (since i found it to be noted in fat letters at reprap.org), the axes do seem to be automatically corrected by performing G30 via G32 - only the wrong way round, so the error is getting bigger but at least it is changing now
I will keep you posted hopefully tomorrow
It's quite common to need to correct more than the calculated amount. I think this is because the connections between the leadscrews and the bed are not the perfect ball joints that the model assumes.
After rewiring stuff to have the four axis table motors hardwired in clockwise fashion too (increasing clock time = increasing motor channel numbers) and changing the absolute endstop positions to where they are (at the maximum positions) I cant get them to be respected by the software anymore (They were working fine before when that position was programmed to be X0 Y0). The endstops are flagged when hit so activity is still correct, of course, the maxima are displayed correctly and the direction of the motors is correct but the motors dont stop when the endstops are hit during homing, poor me - and poor machine
The endstops immediatly take effect again when I say they were at the low end by M574 X1 Y1 S1. But then, of course, my coordinate system and motor direction is the wrong way round again (elswise homeall.g would not work anymore, funny enough).
This is the code that i thought that should work but doesnt:
M555 P1 ; Set firmware compatibility to look like RepRapFirmare
M208 X311 Y231 Z225 ; set axis maxima
M208 X0 Y0 Z-1 S1 ; Set axis minima
M574 Z0 ; Define unused microswitches
M574 X2 Y2 S1 ; Define active high S1 microswitches at high XY2 or low XY1 end
M558 P5 X0 Y0 Z1 H3 R0.2 F7000 T7000 I1 ; Set Z probe type to switch and the axes for which it is used, the dive height H
G31 P600 Z0 ; Set Z probe trigger value, offset and trigger height
M557 X0:310 S310 Y0:230 S230 ; Define mesh grid X limits and S spacing
M569 P0 S0 ; Drive 0 (X) goes backwards
M569 P1 S0 ; Drive 1 (Y) goes backwards
M569 P2 S0 ; Drive 2 (Z) goes backwards
M569 P3 S1 ; Drive 3 (E0) goes forward
M569 P4 S1 ; Drive 4 (E1) goes forward
M569 P5 S0 ; Drive 5 (Z1) goes backwards
M569 P6 S0 ; Drive 6 (Z2) goes backwards
M569 P7 S0 ; Drive 7 (Z3) goes backwards
M569 P8 S0 ; Drive 8 (Z4) goes backwards
M584 X0 Y1 Z5:6:7:8 E3 ; Apply custom drive mapping Drives 5,6,7,8 are driven as one
M671 X0:310:310:0 Y0:0:230:230 S2 ; Z motors are at coordinates 5:X0Y0 6:X310Y0 7:X310Y230 8:X310Y230
G1 Z3 F3000
G1 X320 Y240 F7000 S1
G1 X-5 Y-5 F1000
G1 X320 Y240 F300 S1
G1 X-115 Y-155 F7000
G1 Z-230 F3000 S1
G1 Z3 F3000
G1 Z-230 F100 S1
G1 Z3 F3000
Your M574 command says there is no Z endstop (M574 Z0), but your homing file is set up to use a Z endstop, not a Z probe. So of course it doesn't stop. Do you have a Z endstop switch, or do you intend to use a Z probe for Z homing?
Hej, the x and y endstops dont take effect, z-probe as been working fine
Are you saying that changing which outputs the Z motors are connected to has stopped the X and Y endstops from terminating a G1 S1 X or G1 S1 Y homing move?
If so, is this a Cartesian or a CoreXY machine, and are you using Duet WiFi or Duet Ethernet?
Clockwise reconfiguration worked, 4 axis autolevelling of the bed is now working (i also upgraded to 1.20)! thx!!
Just one more question for the night:
I was using M557 X0:310 S310 Y0:230 S230 before and that did a nice asymmetric 4 point scan of the bed for the heightmap.
After upgrading it stopped after the second point and said too few point for cheightmap… so i tried a smaller spacing like this:
M557 X0:310 S155 Y0:230 S115 which did the trick, only that I get a six point mesh instead of the expected 9 point now.
Should be nine points right at positions X0:155:310:155:0:155:310 Y0:0:0:115:115:115:230:230:230 right?
M208 X310 Y230 Z225 ; set axis maxima
M208 X0 Y0 Z-1 S1 ; Set axis minima
Your Z probe X and Y offsets also affect how many points will be probed, because they may indicate that some of the extremeties of the grid defined by M557 are not reachable by the probe.
X, Y and Z offsets are set to zero for the time being, doesnt help. I also played with the limits settings, doesnt help either.
Am i missing a typo here: M557 X0:310 S155 Y0:230 S115? It is probing both directions with a 155mm spacing.
If i say M557 X0:310 S100 Y0:230 S50, it is probing both directions with a 100mm spacing, obviously its ignoring the second S parameter when i run the "mesh grid compensation" function of the Duet web interface (initiating the G29 command).
You can't use two S parameters, but in firmware 1.20 you can use for example S155:115 or S100:50. The first value is the X spacing, the second is the Y spacing.
Bed levveling is working smoothly now to the next step: The chamber heater is built, a radial fan and 2x50W heat cartridges (not too much power but we will see how warm it get in there in combination with the heatbed). Using an external power supply at 24V 3A (cartridges wired in parallel) it levels at about 90°C with the fan blowing at a decent amount of air through it. However trying to power it via E2 on the board, driven at 24V too (450W power supply) it seems to be doing something but barley reaches 25°C when i set it to 50°C via the webinterface. So here is my configuration, is it waiting for the tool to heat up or something?
M141 H2 ; Assign chamber heater to heater 2
M143 H0 S125 ; set maximum bed temperature
M143 H1 S480 ; set maximum hotend temperature
M143 H2 S80 ; set the maximum chamber temperature
M301 H0 P-1 ; Set bed heater to bang-bang mode
M301 H1 P-1 ; Set bed heater to bang-bang mode
M301 H2 P-1 ; Set chamber heater to bang-bang mode
M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for bed heater 0
M305 P1 X104 ; Assign TC daughter board channel 1 to H1 hotend heater
M305 P2 X201 ; Assign PT daughter board channel 1 to H2 chamber heater ;
M305 P102 X200 S"Chamber 2" ;
Does it give a heater fault? You may need to tune it using e.g. M303 H2 S50 even if you intend to run it in bang-bang mode, to prevent the heater protection kicking in.
Naa its not giving a fault but yes M303 did the trick and thanks again!
Moin, finally finding time to continue on my printer… Opposite to my previous comment i found that i can only initiate the chamber heater directly after running the m303 autotuning routine. When the Duet is turned off and on again, the chamber heater does not respond (it says active but its not actually heating) when i set it to 60°C e.g. I have used the m500 command after autotuning.
Do you have command M501 near the end of config.g, so that the M307 commands that were written to config-override.g get executed?