@dc42

With the new binaries, I did not have any SPI resets so far. 👍

@OwenD said in M291 oddities on both DWC and PanelDue v3.5.0b1:

Trying to understand how there might be 8 blocking messages already in a queue before one of them blocks further messages being added

8 blocking messages would be unlikely which is probably why dc42 chose that queue length. AFAIK there can only be 1 blocking message per input so you would need to have a blocking message on PanelDue, DWC, UART2, Telnet, and both file queues to get to 6 blocking messages!

@Adrian52 @OwenD this is a known issue in 3.5beta1 that will be fixed in beta2.

@OwenD this turned out to be a DWC bug, and it has now been fixed.

@dc42
Great news!

@OwenD Thanks, I've got a fix ready. The indices in the Extra section of the tools panel were off.

@Alex-cr if a new DSF build is not needed then I will probably provide new RRF binaries to fix this at the end of this week. If a new DSF release is needed, we will aim to release beta2 next week.

@dc42 Ah ok, that makes sense then, thank you 👍

@chrishamm Thanks, i managed to print screen the part of the logs when it happens, but i don't see anything weird on the logs...LOG.png

@chrishamm Oh well, it happens 🙂 Not the first time, not the last time 😄

@OwenD Thanks for reporting this. In fact, in DSF and DWC the driver type is a DriverId object with board and driver properties, but this is misleading in the object model explorer where it should be a string. I've got a fix ready for 3.5-b2.

@dc42 thanks

@dc42 awesome, will test soon! Thanks a lot! 🙂

i just came across this thread. i just upgraded my CoreXY printer into an IDEX dual markforged kinematics printer, and i now experience this same jitter behavior.

after reading this thread, this behavior must be inherent to this type of kinematics. with CoreXY, the single head is equally tensioned from both sides with 4 belt connections. with dual heads, only 2 belt connections are present on each head. additionally, when the Y gantry moves, the stationary head still has its motor turn in the opposite direction to counter the drag movement.

for whatever reason, the stationary head is slightly out of sync. or possibly because the belts have the long/short end as mentioned earlier, there is slight jitter movement of the stationary head.

i tightened my belts and this greatly reduced the behavior. but its still present on violent acceleration moves. its noticeable because the stationary head is parked on the end stop, and the endstop clicks everytime the head jitters.

This issue is now fixed. See https://forum.duet3d.com/post/303514 for more details.

This issue is now fixed. See https://forum.duet3d.com/post/303514 for more details.

@oliof the work on supporting those displays is not yet complete. In particular, the code to allow values to be changed when an item such as desired temperature is touched has not been written yet.

In order to achieve a satisfactory speed, these displays need a dedicated high speed (15MHz) SPI channel to drive the LCD. The touch screen interface needs another SPI channel, but the standard shared SPI channel would probably suffice for that.

@dc42 said in Unexpected behaviour - 3.5.0b1:

@OwenD thanks, I'll list this as a known issue. I'll probably replace the use of M0 to cancel tuning by M303 H-1 or something like that.

That would make more sense in my mind as it avoids stop.g being run.
I'll mark this as solved for now.

Ha, I was about to ask the same, thanks for updating the documentation! 👍

@Phaedrux Thank you! I've done this and will test it for a while.