Expansion timeout default behavior

[janusofdoors]

I've been using the Roto Toolboard for a few months now and while I think it's overall a very nice toolboard I do have one very real complaint about it that also has to do with RRF. The XT30 connector used for power+data is far more likely to come loose than the Toolboard 1LC and thus drop the connection. And before anyone asks, yes, I do use strain relief on the cable. This has been enough of a problem for me that I've gotten into the habit of pushing in the connector before i start a print to make sure the connector is fully seated, as even a slight amount of wiggle will cause a disconnect. This would be fine if the default behavior on timeout was to stop any moves/print, however as I found out this morning this is not the case. I forgot to reseat the connector before starting a print and during the Z homing the XT connector must have wiggled just enough to lose connection, causing a nasty crash and a couple of lines to be gauged into my PEI sheet. Luckily I was in the same room as the printer and although I had my back to it I was able to slam my Emergency Stop button after only a couple of seconds.

After looking through the events section on the Duet wiki I see that I can set the behavior on expansion timeout by creating a expansion_timeout.g file under sys, which I've now set to do M112, however if no file is present the printer just issues a warning and continues on, which is exactly what happened in my case. I would consider myself something of a RRF veteran at this point, I've been using Duet hardware and RRF for 5+ years now, and have written bash and python code that connects to the object model and writes to a database, takes photos, etc. My point being; if I was unaware of needing an event.g file to cover this contingency, I seriously doubt the average user would have any idea. I think the default behavior on connection loss if no event.g file is found should be to immediately stop all moves and issue a warning.

I also prefer the VH and ZH connector on the toolboard 1LC to the bulky XT30 connector, and I hope any future Duet toolboards go back to using those instead.

[dc42]

@janusofdoors I am surprised that you are having difficulty with the connector losing contact. Can you post a photo showing the cable connection to the tool board and the strain relief you are using? Is the XT30 2+2 plug loose in the socket?

The only time I've had an issue with the XT30 2+2 is when the cable had been hand-made and the CAN pin crimps were not pushed all the way into the plug housing.

[janusofdoors]

@dc42 You are indeed correct that I previously made my own cable and although it worked at first eventually it gave me trouble from the data pins not being fully seated. Not sure how they get them in there without damaging the wires. I switched to the included cable after having issues and that's when I had the crash. I have redone my toolboard mount(you can find it on Printables) and I think the issue with the connector should now be resolved.

I still think the default behaviour on connection loss should be to stop any moves.

[T3P3Tony]

@janusofdoors glad you have worked out what the connection issue was.

The reason we have the event is so that different machines can have different responses to loosing can connection, and also different responses depends on the specific expansion board that has lost connection. There is unlikely to be a default that everyone is happy with, and changing the default does mean that anyone upgrading has to notice that the default has changed and take action to create event files. I do think having the config tool generate an example event file that acted differently if a job was running or not and.paused during a job could be a good compromise.