Motherboard-Extruder Communication Questions

The following statements I determined by guessing and digging through firmware source code and external sites:

-Despite it being a hack, the default extruder controller configuration is for stepper motors using the h-bridges, not external boards or DC motors.

-Extruder stepper commands are sent only via I2C pins from motherboard to extruder, not the RS485 system. This is so an external stepper controller board could just be hooked up on these pins from the motherboard. This also means that putting an actual I2C device on the bus could result in very bad things.

Are these correct? This is definitely information that needs to go on the Motherboard, Extruder Controller, and Wiring pages, but I am not certain if I have it quite right. This information is necessary to actually making the electronics work, so this should be documented as soon as it is confirmed. I guess I could do it if no one with more knowledge or understanding volunteers.

Also, would it not make more sense to have the stepper commands transmitted through the RS485 as seems to have been done before? Then, a configuration setting in the extruder firmware could select whether to use the H-bridges or another motor driver. This would keep the extruder hardware handled by the extruder controller, and, since the extruder controller has more free pins than the motherboard, could avoid overlap, confusion, and damage with the I2C bus. It would also eliminate the need for a redundant motherboard-extruder cable.

Yes on both counts

The timing on step pulses is too tight for the serial link as far as I know, and hooking an external stepper driver to those pins is almost necessary for proper extruder control

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Thanks. That clears up some confusion, although I wish I could have figured it out sooner.

Do you know if it would be possible to move some of the functionality onto the extruder controller? It seems like it could do speed control, ramping, and pulse generation itself. Then, the motherboard->extruder signals would be the feedrate aspect of the G codes, much less data than individual step pulses. The only question is whether that would still be too tight for the serial line.

It would have the same benefits of eliminating I2C bus abuse and keeping with the Motherboard->Extruder Controller->extruder hardware hierarchy, if the timing didn't end up being a constraint.

On the other hand, I guess there isn't going to be much more work on firmware for these boards. I didn't come across the Gen 7 stuff until just now, and already I'm trying to decide whether to use that for the next machine or as a replacement for the current one. I guess that will depend on how quickly mechanical stuff comes together...

Anyway, thanks for your response; I should be able to get all the electronics going together now.

generation 7 electronics seem to be very experimental...

While Gen7 has indeed it's first board just running these day, there is a plentitude of other boards not or no longer using an extruder controller board: Gen2, Gen6, Pololu, RAMPS, ... about anybody designing electronics drops RS485 and the secondary ATmega, except for the Gen3 makers, of couse.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I can see why people drop the extra board(s). But I for one like the modularity of the gen3 solution. I can easily upgrade a component if I want to...