Add Demon dock sensors

[3DPrintDemon]

Add a community directory for DEMON_DOCKS

This system allows active tool sensing with load cell confirmation for all attached docks with simple & accurate switch connection to a non-critical MCU.

DEMON_DOCKS will auto scan for empty docks at startup & disable sensing for those docks. They can be added back into active docks (or removed again) at runtime by command/macro button. The docks can be set to warn only of a potential problem, raise errors if not printing, PAUSE the print if printing, emergency stop if not printing, or emergency stop when printing.

The load cell dock/undock confirmation can be set on/off at runtime.

The system warns of:

• Undocked tools at startup that will be ignored
• ignored docks during tool changes
• inactive tools undocked at any time
• problems during non-printing operations
• load cell readings out of range
• docking failures - printing & non-printing
• pickup (undocking) failures - printing & non-printing

DEMON_DOCKS then takes specified actions for each type of occurrence.

It can even pause a tool change while printing if a problem is detected!

[codur-design]

Shouldn't these files go to https://github.com/BondtechAB/INDX/tree/main/community ?

[3DPrintDemon]

Shouldn't these files go to https://github.com/BondtechAB/INDX/tree/main/community ?

Bondtech's choice there. I'm easy

[ogland]

Thanks for offering this up, and sorry it has sat since August. The dock itself is a nice piece of work: keeping the standard geometry so installs and dock placement do not change is exactly the right call and makes it a drop-in rather than a rebuild.

What I would like is to take the macros alongside it, as a companion PR, and merge both or neither.

The reason is not the CAD, it is what the CAD is for. The README here describes a system that can pause a print, raise errors, abort a tool change mid-print and trigger an emergency stop. If the hardware ships from this repo and the logic lives in DEMON_INDX, then someone whose print emergency stops at three in the morning opens an issue here, and we are supporting behaviour we do not own or version. That is not fair on you either, because it puts you on the hook for our users.

That is what makes this different from the 2020 dock already in community. That one is a passive printed part with no behaviour attached. This is an accessory whose value is the code.

No rush on it at all. If the macros are not ready to review, I would rather this PR waited until they are than went in half. It has already waited a month because of me, so another few weeks is nothing.

Two smaller things for whenever it does move.

Put it under community/1_printer_agnostic/demon-docks/, following the shape of the 2020 dock: CAD/ for the step files, stl at the top level, preview.png, README.md. codur-design raised this back in August and you said it was our call, so that is the call.

Export the two dock STLs as binary rather than ASCII. They are currently coming in at 175k and 183k lines of text, roughly six times the size of the same mesh in binary, and once it is in git history it stays there. Your soldering jig is already binary, so you clearly have the option in your exporter.

On the wider question, since you have effectively prototyped a feature for us: dock sensing is genuinely interesting to me as something INDX might support first party. It overlaps with work that landed this week, where Z homing now gates on a real load cell reading rather than trusting a saved tool number, and with #29, which was the same class of problem.

If it does go that way, my one firm constraint is that it has to be strictly optional and never assumed. No sensors present has to remain the default and has to work with no config changes, no new required sections, and no macro that errors because a pin is not defined. Most INDX users will never wire a switch into a dock, and their tool changes must not get slower, noisier or more fragile because the capability exists. Optional in the sense of genuinely absent, not in the sense of a flag set to false.

Worth saying clearly that none of that is a condition on this PR. Your version can live in community on its own terms whatever we do. I just wanted you to know the thinking, since you have put real work into the problem and I would rather you heard it from me than found out later.

[ogland]

Heads up: #96 is now on main and covers the main reason for dock sensors with the load cell alone. Every pickup is checked against an empty-head reading taken seconds before (retry once, then pause or stop), every park checks that the tool's preload is gone before the head moves on, and a possibly half seated tool blocks G28 and tool changes until the head is checked by hand. What sensors would still add is knowing a tool is missing from its dock before going to fetch it. If you want to keep going with that, the earlier points still apply: the macros in a companion PR, the community/1_printer_agnostic/demon-docks/ layout and binary STLs. The macros should hook in next to the #96 checks rather than around them.