[FR] Quick Tool Change / I2C toolhead

[madhunm]

Feature Request

Hello,

My team and I would like to have support for a 'toolhead' we are developing. Its primary features are:

1. I2C temperature sensing
2. I2C Fan control
3. Hall effect filament movement and diameter sensor
4. I2C LED Control to indicate heating status
5. I2C Extruder motor multiplexer (True mixing ?)

The total number wires that will run from the controller board to the extruder head will be:

1. One VCC (for heater and fans)
2. One GND
3. I2C Pins (SDA and SCL)

We would be bringing the STEP and DIR for the extruder motor channel to the extruder controller board... An I2C processor will turn those two signals into several physical stepper motors...

We would like to understand how the feature request works; we dont mind attaching a reward for the same.

The entire project will be OSHW.

Thanks!

[thinkyhead]

One piece of code that uses i2c directly is the digipot_mcp4451.cpp file, so that's a good place to start for guidance on implementing a self-contained new feature that uses i2c.

Marlin includes an i2c bus under the EXPERIMENTAL_I2CBUS feature, and this has been used for some real-world implementations. However, none of the features in Marlin uses the TWIBus class, so examples are hard to come by. However, there is this branch which implements a remote Z axis over i2c connected to a second board running a Z-axis only version of Marlin. The implementation details are explained in this thread.

For most cases there's no need to implement a protocol, as in the above examples. The device will already have its address, commands, and replies specified, so you'll only need to poll it periodically.

I2C temperature sensing

Marlin does ADC conversion using a timer interrupt, but the temperature readings are picked up and used within the program loop. So, using i2c means the ADC parts can be dropped, saving cycles, and manage_heaters can just do an i2c request.

I2C Fan control

Pretty simple. Marlin doesn't yet encompass the concept of a fan type. They are currently all assumed to be PWM. The stepper interrupt that moves the stepper motors also changes the fan speed. That logic would remain the same, but the new value would be written to a global (for example, i2c_fan_speed[0]). The main loop would watch for the variable change and do an i2c send to update the fan speed.

Hall effect filament movement and diameter sensor

The Prusa MK3 uses frickin' lasers! Marlin has support for a filament width sensor using an analog pin, and thus ADC. If the sensor is implemented over i2c it saves a lot of computation, even polling 20 times per second.

I2C LED Control to indicate heating status

Heating status is displayed automatically in Marlin if you have one of the color LED options enabled, plus PRINTER_EVENT_LEDS. For a single RGBW LED or multiple LEDs using the same color, these are the current options:

• RGB_LED / RGBW_LED - 3 or 4 direct PWM / digital pins.
• BLINKM - A simple i2c-controlled LED. See blinkm.cpp.
• PCA9632 - More complex i2c LED. See pca9632.cpp.
• NEOPIXEL_RGBW_LED - Adafruit Neopixel, using their library.

I2C Extruder motor multiplexer (True mixing ?)

E motors need to be well-synchronized with the XY motors, so a multiplexer has some limitations. The Prusa multi-extruder system can't do mixing, so it only needs to route stepper signals to one stepper at a time. A multiplexer that included the ability to mix would need a means to set the mixing ratio, and then on-board Bresenham logic to detect input steps, increment and reset counters, and proportionally redistribute steps. Note that from Marlin's perspective there's only one E axis.

---

These are some initial notes on your needs. When someone has the time to work on this, do you have all your hardware components already well-specified? Do you know the i2c addresses and do you have datasheets on how to communicate with these devices? Any guidance you can provide in advance will help to prime the gears.

[madhunm]

@thinkyhead

here is a quick concept for the print head. I am omitting the extruder motor for now; it can come later.

Let me know in case you forsee any issues with this.

[bobc]

Looks like a very interesting project! I would not choose I2C for remote comms, it will be interesting to see how well I2C works in a noisy environment. It also seems that if you have an MCU, it could perform the functions of the MAX76615 quite easily.

I also wonder if you are looking at using AVR as main controller, running steppers over I2C seems like it would push AVR beyond it's limits.

[madhunm]

@bobc

The stepper(s) when done, will be driven by the MCU directly... they are just switched over I2C. However, that part of the project will come later.

Right now, the focus is on only the print head.

Regarding the MCU handling the functions of the MAX6615, I understand that; however, since I dont know the direction of the project yet, I have split them into two seperate parts.

[bobc]

Ok, I thought you were more advanced with the hardware design, it sounds like you are at the early planning stage.

I know there is a tendency to drive ahead with the "easy stuff" first, but I would establish a Proof of Concept first with the difficult parts prototyped to verify it is feasible.

You refer to "VCC", that is the logic voltage, i.e. 5V or 3.3V. I looks like you actually mean 12V here.

[madhunm]

@bobc you are right; it is not 5V, it is actually 24V. The fan control is most probably going the MAX6615 route; I have ordered parts to prototype.

[Grogyan]

My 2cents.
Reading the OP, a lot of these features would not be ideal using I2C.
These feature, and more, ideally require a CAN bus.

I2C is a short range bus, which has minor EMI immunity.
SPI has better EMI immunity and is also limited by range. Not ideal for more than a few devices running on it.
CAN is a long range bus, has excellent EMI immunity and can have a large number of devices running concurrent on it.

I spent several weeks going through the various bus options, to come up with a better long term solution to the numerous devices and displays that are already in use, and find a future proof solution.
Also, talking with industry experts in automation, CAN bus is widely used because of it's excellent immunity.

I have proposed a Feature Request for Marlin 2.x to have CAN support #7735