Thanks both of you.
That's what I thought, but wanted to check.
If it's alright, I'll add a little comment to the wiki, since the above is not reflected in it.

@pro3d said in Axis homing @max using sensorless?:

@dc42 said in Axis homing @max using sensorless?:

@pro3d what M574 command are you using? S3 should stop when the first motor stalls, whereas S4 should run each motor until it stalls.

Oh.. I was using S3 yes. Thanks, I just configured ZUV independently and got it working but that is not necessary using S4?

That's right, not necessary if you are running RRF3.

Hi Ben. This is an old post, but did you solve your homing? I try to do the same as you did

@adamfilip said in Dual Motor, Dual Endstop for Y Axis:

@fcwilt
how does it know Which endstop corresponds to which stepper?

If Y1 hits endstop before Y2, Y2 should keep going until it also hits its own endstop to square the gantry

The endstops are associated to the steppers in the order they appear in the commands. First endstop in the M574 to the first Y stepper in the M584 and so forth.

Frederick

@Phaedrux - I think you've hit on the root cause with your print head tilt comment. Looking at the relative locations of the probe and nozzle, if we have tilt, I can see where the height map would be affected. (see picture).
05e228af-18c5-4966-8057-a7bac44450ad-image.png

With a height map from a tilting print head, the mesh correction during printing for the same tilt would cause nozzle to crash or fly over the bed on the first layer, depending on the direction of tilt. Our height map data is consistent with this theory, and so is the nozzle crash and flight that we observed. The wiring to the print head is giving us the push or pull force to give the right torques to match this tilt, even though the forces are small. Something must be loose. So much alignment in the data makes me confident we are on the right track. Next will be to unravel what is loose or twisting. My current bet is on the sliding block the print head lives on. How to address it will be a "fun engineering problem".

Thanks to the forum for taking time to comment on this post. As always, the duet forum rocks! Too bad there is not a "best online forum" award.

@coen_l said in Nozzle temp continues to rise:

@fcwilt Great! Temp is stable now. Thank you so much for your help.

Glad I was able to help.

Frederick

@phaedrux said in Z Probe Height set but Z0 is always -0.4mm off:

Well once you have your trigger height measured and saved in some way, all you need to do to re-establish Z0 before a print or anything else is a single G30 at the center of the bed.

I'd recommended process on a Delta is not a single G30 but a G32 before the print provided you do not have a G28 at the end of your bed.g

If you aren't doing some extremely high number of probe points (a S6 run only needs 10 or 12 points) it shouldn't take long and will not only set the proper Z0 but will deal with any shifting from room temp or bumping the printer.

It is easy to put a G32 in your slicers start gcode.

@skhotso said in Z stalling or not moving part way through print:

It doesn't look like there are any soldering issues here.

Agreed, those look like good joints from what I can see.

@phaedrux dropping it down to 20mm /sec does get rid of the warning

What do you have in config-override.g?

@tom33 said in not running pause.g, start, resume,...:

Hi can switch between differents configurations with my machine (due to different toolhead laser, 3D printer). What is the best way to do this ?

https://duet3d.dozuki.com/Wiki/M505

This will let you have different config folders with their own files and macros and let you switch between them. Each could be configured as a different role.

@o_lampe Hehe that would be pretty cool 😄 Although it may be asking a bit too much of the beeper speaker for it to do voice xD I was thinking of a better sound addon, but I might aswell just play the music through the computer at that point lol. (Or a raspberry Pi?) My favourite has to be the Bowser song Followed by Saria's song and then Tetris. It really depends on the song. The more basic the main beat is the better. Some songs you think will be great, and they turn into noise, While others simply defy expectations lol. One thing is for certain, I need more xD

@grantstevens can you post the M915 commands you are using wherever you have them (config.g and your homing files?)

@phaedrux Nope, the config file loads completely successfully both with M98 or at board reset

@fcwilt Thank you very much, this did the trick!
I was thinking too complicated. Sometimes the answer can be that easy.

@phaedrux sure thing:

M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later Board ID: 08DGM-917DA-G4MS8-6JKDA-3SJ6T-T8VH8 Used output buffers: 3 of 24 (17 max) === RTOS === Static ram: 23876 Dynamic ram: 75280 of which 0 recycled Never used RAM 12404, free system stack 172 words Tasks: NETWORK(ready,13.6%,237) LASER(notifyWait,0.0%,70) HEAT(delaying,0.0%,386) Move(notifyWait,0.1%,364) MAIN(running,86.3%,519) IDLE(ready,0.0%,29), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:53:43 ago, cause: power up Last software reset at 2021-12-04 17:24, reason: User, GCodes spinning, available RAM 12604, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Step timer max interval 0 MCU temperature: min 20.5, current 23.2, max 24.4 Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/24/0, gc cycles 0 Driver 0: position 0, standstill, SG min/max not available Driver 1: position 0, standstill, SG min/max not available Driver 2: position 0, standstill, SG min/max not available Driver 3: position 0, standstill, SG min/max not available Driver 4: position 0, standstill, SG min/max not available Driver 5: position 0 Driver 6: position 0 Driver 7: position 0 Driver 8: position 0 Driver 9: position 0 Driver 10: position 0 Driver 11: position 0 Date/time: 2021-12-04 18:43:48 Cache data hit count 4294967295 Slowest loop: 30.98ms; fastest: 0.17ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 1.2ms, write time 15.9ms, max retries 0 === Move === DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 71.59ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.26 WiFi MAC address bc:dd:c2:9a:4a:85 WiFi Vcc 3.31, reset reason Turned on by main processor WiFi flash size 4194304, free heap 25112 WiFi IP address 192.168.1.212 WiFi signal strength -60dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0

OH! and yes it seems to be working. it just made me wonder if I messed something up is all. in new to this and am just wanting to make sure on all my things 😓

@gibsea402 said in Bed mesh compensation BLT:

It is like it is doing the opposite of what its supposed to do.

Can you confirm that your -X moves left, +X moves right, -Y moves forward, +Y moves back? And that if that is true your BLTouch offsets are also the correct direction in relation to the nozzle?

Just wanted to post an update to this solved problem. I went through all my files on this machine and could not find anything that might be causing issues. As a last ditch effort I grabbed a sheet of aluminum foil and flattened it out on the bed and ran a g29 command to generate a height map. the map looked a lot different than the one I had previously generated so I decided to try and do a test print with that height map. adjusted live z and it started to print perfectly.

I think the issue is the pinda 2 probe and the bed probe points with the MK 42 bed not triggering consistently. I am going to print for a while with the height map I made with the foil and will probably buy the MK 52 bed and a spring steel sheet to see if that gives more reliable leveling.