Topics created by Leonard03

@Leonard03 thanks for your feedback and for testing all these firmware builds.

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

@T3P3Tony That's fantastic, thank you!

@T3P3Tony said in M291: cancel vs timeout:

Once concern with making (for example) user action rather than timeout -2 would be a breaking change where peoples existing scripts would not work if they explicitly checked for -1

I thought about that and there might be some ideas for this.
First, don't include an timeout in the M291 line, so the result can never be -2 for example.
Second, in existing macros that works, the only modification that might need is instead of an result = -1 to result <= -1 so the behavior might remain unchanged (right?)
Those are only my ideas. Any feedback is welcomed 😊

@dc42 Thank you very much for taking this issue in consideration! I had really low hopes that this can be fixed because I don't now how many users have this kind of setups and because I'm using the Duet 2.. well, I have no words 😄 Thank you again and congratulations for your efforts and for supporting the Duet 2 boards for so long! ♥

@DaveA @Leonard03 its been fixed in source and will be part of beta 3

@dc42 Thank you for the hint. I will keep an eye on it and if any issues occurs I'll report back 🙂

@dc42 It works! And it works flawlessly!
With this build I've done some multihour prints with many tool changes and they worked perfect, no more resets (at least from thar reason).
For the PanelDue, using PanelDueFirmware-3.5.0-rc7-testcomm DWC is more responsive, more fluid, it updates more often and the connection is more consistent.
As a side note - annoying but don't bother me too much - after some time the DWC disappears altogether. I can ping the board, but no DWC. But until that point works flawlessly. By the way, trying to disable and reenable the wifi module (idle or printing) resulting in a stuckinspinloop when trying to enable it again.

Again, thank you very much for your time and help solving this issue! 😊

Good morning everyone!

First of all, I would like to apologize to you. This was not an issue with RRF but with my own code... Thank you all for your help and support!

Just in case, @gloomyandy and @AndyE3D you were right about M118 in every file in MMU Control. But I has no chance seeing something unusual until I used logging.
@dc42 I am sorry for tagging you here and wasting your time.. was my fault, not RRF's fault..

The problem was elsewhere, right at the beginning, in tpostn.g.
There, were three simple calls: load the filament in the MMU, then in the extruder and last in the nozzle. If during those macros any error raised, the tool change macro continued showing a dialog (M291). But, it can also call errorAction.g which by itself loads the filament all the way to the nozzle, but being called from a "while" loop in tpostn.g, after errorAction.g the while loop was trying to load it again to the MMU. The log confirmed that:

2023-08-02 12:02:28 [debug] Finish: loadToBondtech.g 2023-08-02 12:02:28 [debug] Begin: idlerMove.g 2023-08-02 12:02:28 [debug] Finish: idlerMove.g 2023-08-02 12:02:28 [debug] Begin: loadToNozzle.g 2023-08-02 12:02:28 [debug] Finish: loadToNozzle.g < here the duex.e2stop is configured as a filament sensor 2023-08-02 12:02:28 [debug] Begin: loadToFinda.g < here the duex.e2stop is used to load the filament in the MMU 2023-08-02 12:02:35 [warn] Error: Pin 'duex.e2stop' is not free 2023-08-02 12:02:35 [warn] Error: G1: Failed to enable endstops 2023-08-02 12:02:41 [info] Event logging stopped

In tpostn.g adding a break statement to exit the wile loop solved this problem

Thank you again to all of you for your support! 😊

I have the same behaviour but when manually press pause button, but 3.5 beta2
What can I do?
Thanks

Ah, and as a side note:
As I seen this idea also somewhere here on the forum, I tried to simulate that gcode and the simulation completed without warnings or errors