@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

@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

I will confirm that changing from /?action=stream to /?action=snapshot in the webcam URL and setting an update interval (I chose 500ms), you can get something resembling a webcam slideshow in the window.

af77bca3-3b8b-426a-b5bd-7c9a53809039-image.png

@T3P3Tony Hey Tony,

We found the issue to be regarding the V axis being too low.

Why it triggered only with G2 enabled gcodes remains a question still, but since we adapted the starting codes to account for the V being out of bounds we have not had the issue.

Maybe an improvement is to add the relevant axis number to the errorcode for future firmware?

@moth4017 this is intentional. In previous firmware versions, object model values were reported to a certain number of decimal places. This meant that some values such as the M308 C parameter for a thermistor were always reported as zero. RRF now reports very small and very large values in scientific notation instead.

@gloomyandy Yes that was it, thank you!

@dc42 said in [3.6.0-rc.1] EXP1HCL V1.0a io1.out PWM Issues:

@sebkritikel there was a firmware bug. Please try the 3.6.0-rc.1+1 version at https://www.dropbox.com/scl/fo/0xdvvzgqfrs5abyk75ss8/AL3i6s7z9UacEGYsxiR7pXw?rlkey=xpm61w2jlyqlawwjzy4zsq2lt&dl=0 which is compatible with 3.6.0-rc.1 or rc.1+1 firmware on the main board. This EXP1HCL build contains an experimental feature but that should not affect you unless you are using a linear composite encoder.

Thanks! Just tested both boards with rc.1+1 (mainboard and 1HCLs) and io1.out works as expected.

@sebkritikel thanks. The reason for questions 2 and 3 are that another user reported a minor issue after extruding more than 2^31 steps of filament (which would be 5km of filament in your case) caused by the step counter wrapping round, and I wondered whether your Code 6 report might be related to that issue.