@Serbitar I don't use any sensors on the tool change. I support both using the turtleneck to load and a measured length.
I still have work to do on when something goes wrong

@chrishamm said in 3.6.0 RC1 python perform_simple_code not working:

@achrn There were some errors in the previous 3.5 dsf-python client which renders parts of it unusable with 3.6. Hence I suggest you upgrade to dsf-python 3.6-rc.1, I expect that will fix your problems.

Should 3.6.0 be available by apt install?

I've done apt update and apt upgrade but apt list gives me (inter alia)

All the rest of the packages seem to have gone to 3.6.0 RC1:

@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.

@moth4017 in RRF 3.5 and earlier, each floating point field in the object model is displayed to a set number of decimal places. This has some undesirable consequences, for example the C parameter in the thermistor configuration is reported as zero whereas in reality it has a small but very significant value. For this reason, RRF 3.6 reports very small values in scientific notation instead. What's happening here is that because of floating point rounding error, the final deviation is computed as a very small number instead of zero, which is why 3.6 reports it in scientific notation.

BTW if you use more probe points than leadscrews, the final deviation won't be zero, which is why we report it.

@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?