@chrishamm thanks i missed that on that general page
26f21520-259a-4bdb-b670-a0ebeb48d434-image.png

@Serbitar I suspect that pausing from a tool change macro is going to cause problems. I'm not even sure what the correct resumption point should be if you do that. Having said that I've also no idea what the correct way is to handle a failed tool change. I tend to treat them in effect as a fatal error on my e3d toolchanger and just abort everything, but I can see how on printers that may have "expected" fails during a change this is not really a good solution.

@achrn It should be available via the package feeds as well now.

@moth4017 if the bed isn't completely flat then probing just 3 points may not give the best level, for example one of the probe points might be on a high spot and another on a low spot. If you probe more points then RRF chooses the plane that minimises the total RMS deviation at the probe points. This in turn is likely to reduce the mesh compensation needed.

@Aurimas I can also confirm this has happened a few times on my machines.
If you can make a new thread, Ill post my config.g there for tracking and debugging

Is there any update for this? 😁

@dc42 Confirm the problem is solved!
Thank you for the help and support! Your work is really amazing 😊

@Tech_Sam03 that's because the state changes to busy when that macro starts, then back to idle when it completes.

@PetrKroupa I've found that pre-crimped JST ZH connectors and tails sometimes have bad crimps. Perhaps your cable had one.

Updating the bootloader on a 1LC doesn't work in the 3.6.0-rc.1 build. There is a new firmware build at https://www.dropbox.com/scl/fo/y03luwmbypirbxncla3rk/AAJFLPFsVdFylemyhkXsAac?rlkey=7cq4svp4rzl2ztdffpzq2ghjk&dl=0 that corrects this. The changes in this build are listed at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-360-rc2-in-preparation.

@Phaedrux thanks for moving this to the right place

I'm going to mark this one closed. I initially disconnected the idea of a bad cable because mine consistently worked. I swapped to a different cable and the issue was resolved.

It is strange though, I can consistently replicate 3.5.4 + old cable = works and 3.6.0rc1 + new cable = doesn't work. And 3.6.0rc1 + old cable = works on raspberry pi.

@dc42 it is working now. Thank you.

The problem was in the power supply. But in the 5V power supply for RPi and 6HC. Although it was 5v 6A so it must have been bad somehow. After replacing it, my timeouts are still 0 and no other CLICKs or other problems happen.

In short, when @dc42 assumes something, it is usually right. 😉

Thanks for the help and please close this topic.

@3DOeste said in [3.6.0-rc.1] staggered movement duet2 ethernet:

and did the max flow rate test from 20 to 50mm3.

Was this using the flow tests in OrcaSlicer? I think I've heard that they are not RRF compatible, maybe they use adaptive pressure advance. Also check that the slicer isn't overriding the speed, jerk and acceleration settings in config.g.

What version PanelDue firmware are you using? Check by selecting the 'Setup' screen.

Ian

@dwuk3d this particular bug was new in 3.6.0-rc.1.

@ironhydroxide said in 12864 menu: button V{bool} With W and A"M98" broken:

I'd think this is something with functionality added in RRF 3.5.0-beta.4 when the V{bool} functionality was added.
maybe nobody has tried to force a button width with a Visible bool flag to a macro since?

That's very possible. One for @dc42 to investigate, though!

Ian