zoffset changing every time

Norder

@tinchus
Then the next step would be to measure the geometry and check whether components are deformed or have loosened connections that could cause this behavior.

Phaedrux

@tinchus said in zoffset changing every time:

I have to baby step again, EVEN after I already corrected the offset on the config, and I already checked using G31 that the new offset is active

@phaedrux said in zoffset changing every time:

Please post your config.g and config-override.g

@tinchus said in zoffset changing every time:

It is not possible to do this with the chamber hot, it is at 120 degrees celsius, you would burn your face and fingers...

Understood. However, if you're using the babystep method to modify the Z offset, are you waiting the same amount of time for heat soak to occur? I could see variance in temperature and time resulting in different Z positions. You meanion other printers, are they all identical?

Tinchus

@phaedrux Yes, the probing on the ced start ONLY after 10 minutes of waiting to be sure all temp is stable (actually the variation inside the cmaber is only 3 degrees at the front and back, very stable). I do the baby stepping when the print has already started and printing a brim wich I use to fine tune the first layer by eye (there is a window to see). The other 2 printer are exactly the same, same hardware, same software, same configuration. There is no even 1 single screw different. I have checked the hardware to see if there is something loose, it is all ok.
And the offset variation is very stable: I i print and baby step 0.2 mm, next time the printer is ON and ofsset already corrected and active on config, I will have to baby steps another 0.2mm again... same value as before.

Very weird.

How can I update the firmware to a specific version? Im think on reflashing the firmware? coud it be corrupt or something like that?

Norder

@tinchus
Have you tried copying the most important files such as config.g, homeall.g etc. from one of the two printers 1:1 without any problems and then overwriting the files on the problem printer?
A tiny mistake quickly creeps in that is overlooked.
If the three printers are identical, this shouldn't be a problem.

Google Translate
-- Original Text --

Hast Du schon versucht die wichtigsten Dateien wie config.g, homeall.g etc. von einem der beiden Druckern ohne Probleme, 1:1 zu kopieren und dann die Dateien auf dem Problem-Drucker zu überschreiben ?
Es schleicht sich schnell mal ein winziger Fehler mit ein den man übersieht.
Wenn die drei Drucker identisch sind, sollte das kein Problem darstellen.

Tinchus

@norder it is the way the printer got its config: I just copied the files from the other one

Phaedrux

@tinchus said in zoffset changing every time:

How can I update the firmware to a specific version? Im think on reflashing the firmware? coud it be corrupt or something like that?

Upload the full zip file for the version you want. I don't think it's a firmware issue though.

It sounds like there is a stray command somewhere that is altering the expected value.

@phaedrux said in zoffset changing every time:

Please post your config.g and config-override.g

The results of M122 and M98 P"config.g" as well please.

Phaedrux

@tinchus said in zoffset changing every time:

@norder it is the way the printer got its config: I just copied the files from the other one

If the firmware is the same. The config is the same. Then I suspect a mechanical difference.

Tinchus

@phaedrux M98 P"config.g" ginves nothing, no error, just the green OK
M122:

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.1 (2022-06-01 21:09:01) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J1FD-3S46K-KA8AS
Used output buffers: 1 of 40 (13 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 66952 of which 0 recycled
Never used RAM 132528, free system stack 154 words
Tasks: SBC(ready,0.6%,438) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,267) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.0%,333) TMC(notifyWait,8.5%,58) MAIN(running,90.5%,923) IDLE(ready,0.3%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:20:26 ago, cause: software
Last software reset at 2022-10-06 17:11, reason: User, GCodes spinning, available RAM 132560, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 155
MCU temperature: min 37.8, current 38.2, max 38.6
Supply voltage: min 24.0, current 24.5, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 696, reads 37630, writes 24 timeouts 0
Driver 1: standstill, SG min 0, mspos 280, reads 37631, writes 24 timeouts 0
Driver 2: standstill, SG min 0, mspos 264, reads 37615, writes 40 timeouts 0
Driver 3: standstill, SG min 0, mspos 616, reads 37615, writes 40 timeouts 0
Driver 4: standstill, SG min 0, mspos 680, reads 37631, writes 24 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 37636, writes 19 timeouts 0
Date/time: 2022-10-06 17:31:53
Slowest loop: 179.60ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 8, maxWait 88059ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 486, completed 486, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters 0 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 10990, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 6131/0/0
Tx timeouts 0,0,6130,0,0,4858 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 49406/49406
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2b880
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.1
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 40.44, max time between full transfers: 197.2ms, max pin wait times: 71.4ms/30.4ms
Codes per second: 0.62
Maximum length of RX/TX data transfers: 3266/884

Phaedrux

I still think it's mechanical issue on this printer. Since you have other identical printers you have the perfect way to verify, albeit with some time and effort, you could take the entire Duet and transplant it into the other printer, and vice versa. Does the issue follow the Duet, or stay with the printer?

Norder

@phaedrux
We are of the same opinion.
But what is strange... that it is always about this 0.2mm, which could be more for a wrong command line, for example in config.g or config-override.g.
But you would have to be able to see these files, which you asked for three times.

@tinchus
Please post the requested files (config.g and config-override.g) if you want help here.