@dc42 Aha, great. I've updated the wiki (https://duet3d.dozuki.com/Wiki/M150?revisionid=HEAD), hope that's OK .

@dc42 Aha, great. I've updated the wiki (https://duet3d.dozuki.com/Wiki/M150?revisionid=HEAD), hope that's OK .

Based on the docs for M150 (https://duet3d.dozuki.com/Wiki/M150) there is support for RGBW strips. I know marlin has a W-parameter for controlling the white channel, but there's no mention of a W-parameter on the RRF wiki.

Is it possible to control the white channel separately?

• If yes, what parameter do I use, or how do I control it?
• If no, what will be the behavior of the R, U and B parameters on the white leds?

@droftarts Thanks. Seems it will be hard to patch an accelerometer to v1.0 unfortunately. That might be a suggestion for a future revision; make the I2C pins available on test pins.

Adding a Sammy C21 will be more realistic. Without highjacking the topic too much; having a toolchanger, would adding one to the toolhead make sense, so it would be used for / shared by multiple tools? Or would supporting such thing in the firmware be unlikely?

Nice work, great to see that you listen to customer feedback.

Some feedback/questions from my end:

• I do like the crimped connectors, but nice to see that the holes are still there for people preferring screw terminals. A suggestion for a future revision would be to align these holes so that one solid row of screw terminals can be mounted instead of separate sets. This makes the terminals a lot more sturdy and one would be less likely to damage pads or connectors if using too much force fastening the wires.

• As a v1.0 owner, I'm a tad sad to see I'm missing out on all the accelerator fun.
  Therefore the question whether I (being familiar with patching hardware, soldering and epoxy) would somehow be able to retro-fit an accelerometer to the v1.0 hardware. I was thinking about some daughter board holding the accelerometer and some passives and then connecting it to some pads/traces.

  • If possible, any docs on what to do, or schematics to look at?
  • In either case, it might be a good idea for a future revision to break out every (unused) signal/pin to testpoints so patch boards can be made.

@dc42 This is indeed interesting for debugging, nice .

For a more general overview, another solution could be to implement something more generic where certain entries of the object model could be persisted on the dashboard (either with manual refresh or some kind of automatic refresh (e.g. every second, every 5 seconds, ...)).

Using M950 one can setup various J-inputs. This could for example be used for tool detection (are all tools docked). These J-inputs can then later be used as source for M581 triggers.

For debugging purposes, and for general overview (such as on a toolchanger), it would be nice if DWC would show the current state of these J-inputs.

This could be designed as an extra line in the status-box (below "speeds" and "sensors") where it shows J0, J1, J2, ... (as configured) together with there state. As an alternative it could be added in the tools-box under the "extra" part. This first (inside the status-box) would be preferred to have it always visible.