@dc42 I have been watching for half an hour now using the initial daemon.g code - no more 2000°C spikes with the new firmware!

Now that was a supersonic bugfix! 🚀

Thanks! 🙂

@lycean if you use the lates firmware at https://www.dropbox.com/scl/fo/3y4agkmfzfmqcifuecqo3/h?rlkey=j0kibs1tubm5dfj7o2vz1vbzj&dl=0 then you won't need to change your macros.

@SumoSniper @adambx @NineMile @o_lampe I have put new firmware binaries at https://www.dropbox.com/scl/fo/3y4agkmfzfmqcifuecqo3/h?rlkey=j0kibs1tubm5dfj7o2vz1vbzj&dl=0. The main difference is that multiple file readers are now only used if your job file or start.g file uses the new M606 command to fork the file reader (see https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m606-fork-input-file-reader) . Therefore, unless you use that command, macros will only be executed by one reader, which should solve the problem.

If you do use M606 then the behaviour will be as it was previously from that point onwards, and you will need to ensure that any macros executed subsequently to that M606 command are suitable for execution by both file readers. For example, you can ensure that any global variables needed are set up before the M606 command executes. Please note, testing of the M606 command is still in progress.

Thank you all for your feedback! In conclusion, we all agree that for heavier machines, hardware limit switches are a must-have or are even mandatory for machines that are used in professional/business environment.

@dc42
@T3P3Tony
Are the X and Y moves considered probing or travel moves in G30 Pnnn?
I assumed that moves in X and Y are travel moves that position the head above the next probing point, and only the following move in Z is the actual probing move. Therefore, the limits in X and Y should be respected like for any other travel move. This would avoid raising faults or adjusting the bed.g macro.

@timschneider thanks. Please file an issue at https://github.com/Duet3D/RepRapFirmware/issues.

I think a related issue is that there will be a problem if the current machine Z height plus the Z hop amount exceeds the Z maximum defined in M208. You could mention this in your issue report too.

@dc42 The problems seems to have gone away with the new RC3. Thank you for whatever was fixed 🙂

Thanks, for the first time it looks really better.

@mule glad to help. Thanks for reporting this.

@jay_s_uk the new M950 K parameter when creating a fan should allow you to fix this.

ready to test when you have something to try

@Aurimas Yours was the only BLtouch related posting I saw on RC3 . Mine seems to probe OK, I tried it twice and a G32 just in case and they work fine. . Had that error at first and went looking to see if something changed in the config.

@madeinta1wan You could use a bed mesh, and assuming that the bed levelling screws are equidistant, create a mesh where the probed points are above the levelling screws. Then run mesh bed compensation, which should show which screws need adjusting.

Ian

allora,ho rifatto la sd della stampante ed ora funziona

@Phaedrux

Well said..... in a clear and polite manner. Agreed

Just a little heads-up about the STL-splitting.
It's a bit tedious, but doable with OpenScad. Maybe fusion360 or other CAD programs have better options, but it's a starting point.
I've chosen a coarse interweaving pattern, which is 3 layers high.
Here are screenshots of a split object and how it looks in PrusaSlicer.
multimotion_splitOScad.jpg multimotion_splitSlicer.jpg

@oliof said in Multiple motion system homing malfunction:

@SANJR

daemon.g while (true) M596 P1 G91 while (global.weldtorchstate == 1) ; maybe an if-condition would be better here? G1 H4 U99999 F1000 ;selects the U axis & sets the feedrate G4 S0.2 ; this delay should be related to the while(true) loop

Thanks Oliof

Its good now

@gloomyandy said in Scanning Z probe G31: invalid Z probe index:

@charliedrums said in Scanning Z probe G31: invalid Z probe index:

uet SZP firmware version 3.5.0-rc.1+ (2023-11-20 12:50:20)

Your SZP does not seem to be running 3.5.0-rc.3. Probably best to make sure all of the boards are using the same version.

Totally brain farted, this was the issue. I was trying to update the SZP board trough putty with sudo apt update but it kept saying everything was updated. Fetched the rc3 update bin file for the SZP from the github directory and uploaded it trough DWC and installed it from there. That seemed to be my problem. I don't get the G31: invalid Z probe index at start up anymore. Thanks everyone for the help.

@derBruchpilotPro and @KP0005 thanks for confirming the fix