Ok, here's my new idea for standardized ribbon cable pinouts,

Ok, here’s my new idea for standardized ribbon cable pinouts, based on the discussion here: https://plus.google.com/105535247347788377245/posts/LkE6hwH8mri

I’m not as happy with this version yet as I was with the last one, but I wanted to open it up for comments.

I changed the motor/endstop connectors from 8-pin to 10-pin because those parts seem to be more common and easier to source, but I’ve left the pins unchanged because I like that arrangement. It degrades down to six pins if you have unpowered endstops and don’t need the MAX endstops, and the it’s still possible to use the 8-pin versions. I thought about using the extra pins to double-up the power and/or ground pins, but I decided to leave them NC for now, in case a better use arrises.

The extruder and hot-end connectors lost one pin each of power and heater. They still have capacity for 4A if the low-quality cables, which is more than enough for 40W @12V. The extruder cable can no longer be less than 20 pins, but the hot-end cable can be reduced to from 16 to 12 pins (while staying centered) if you don’t need the extra current, and this does have the advantage that the cable reduction will only be on the breakout board set (from the extruder board to the hot end board, along the bowden cable), so controller boards can be made with the full extruder connector and only the breakout set needs to change.

The pins removed from these connectors have been replaced with I2C. This allows for connection of I2C EEPROMs for UFID at the extruder, and if a small microcontroller is added to the extruder, other “smart” devices like sensors for filament presence, diameter, and movement can run through it. I know that I2C isn’t the ideal protocol for this type of cable run, but the applications should not require high speed, and the alternatives have bigger disadvantages. One advantage of I2C is that if uses one pair of wires for many devices, and most I2C devices I’ve seen have pins to determine their address, so jumpers on the board can be used to differentiate multiple extruders for these functions.

i2c is a nice option. Have you considered CAN. Yes it is not native supported on most 8Bit controllers. Some of the ARM device provide support for CAN. For i2c there is a great range of devices like port expanders and eeproms and sensors. I would be happy to have a standard pin out.

I just thought about I2C the other day when I saw that Marlin now supports real-time filament measuring devices, but only through an analog input. But we’ll just have to see how well the protocol works next to all the other high-emi leads.

I’m not too fond of running the pwm fan next to the scl i2c signal, it’s going to have a fair amount of crosstalk and may trigger false edges on devices. Similar with the probe an i2c clock.

Guys. I2C (by its name) is an Inter-Integrated-Circuit bus. It is not intended to be cabled off-board and if you do it will be necessary to buffer the signals or run a low speed. The low speed required may not be natively supported by controller hardware and then you will be forced into adding a software implementation.
Cheap hardware implementations will not buffer the signals and the result will be erratic operation. Also consider that even the present implementation of I2C in Marlin (as used with controllers like the Panelolu2) is not without timing problems.

@Neil_Darlow any alternative that is supported by the common MCUs and made for off-board connectivity?

@Thomas_Sanladerer All serial buses driven directly from the microcontroller will be (potentially) problematic. I am not against I2C but I know that someone is going to do a minimal implementation and it will cause problems.

Regarding addressing of I2C devices, you need to be aware that some manufacturers only produce devices with particular addresses. Other addresses are available to special order and may cost more.

I do hope that UFID has not restricted itself to I2C as the memory media interface. It should be interface agnostic to allow for future developments in technology.

I think that you will be getting away with using I2C up to about 60-80cm length of cabling. I’ve been running LCDs with an I2C interface in reasonably noisy environments without glitches with the right guarding between signals and at I2C mid range clocks.
I do agree that is not the best solution without buffering but it should be on the safe side running it at it’s lower speed configuration.
CAN does seem to be a lot more suited for the need but not many low end controllers have it integrated.

I’d be tempted to suggest something like RS485 if you want noise immune. It’s common bus multi-drop so handles many devices on just two wires. Downside is that you need driver chips. Upside is that it uses the tty serial ports on most devices and conversion between RS232 TTL and RS485 is fairly easy in software. Just adding some bus control/addressing code.
That being said, put a ground line(Or things rarely triggered, like an endstop) either side of I2C, run it at low speed and use beefy pull-up resistors and its remarkably good. It’s meant to go through the logic board of large, CRT TVs… Not exactly noise free as it is. :slight_smile:
There’s also nothing to stop you just making those two lines as ‘comms’ and suggesting a layout for RS232/RS485/I2C to cover all your bases.

@Neil_Darlow ​ HDMI for example uses i2c for CEC for example or EDID. It is definitely not on circuit. But cables are probably shielded better. I am not sure how robust i2c is against interference.

I’ve had endless problems with noise and crostalk when running motor drive with 5v endstop logic level in the same bundle.

I suspect based on experience with 12c you’ll have the exact same problems going off board.

RS485 or CAN would be a lot smarter for “next generation” planning…

@Christian_Ege_grauga ​ HDMI uses I2C for DDC. CEC is a one-wire protocol. HDMI employs good quality cabling and the drivers/receivers are well-specified. Also I2C on HDMI is used in a point-to-point fashion not a multi-drop bus.

I have designed many ribbon-cable connected modular systems. The biggest problem is ensuring that rise and fall time specifications of the receiving device are met. Of course, appropriate transceivers help but my experience of typical RepRap hardware is that they will not be used.

I considered RS485. It is better suited to the wiring system, but using it would require not only a converter chip on each side since our microcontrollers don’t have native support, but there would also need to be a microcontroller on the extruder. I wanted to make that an option, but not a requirement for using UFID. How much cost would it add to have two of the RS458 chips, plus either an ATtiny or one of those tiny Cortex-M0 MCUs? There would also need to be a programming port, voltage regulation, etc., which makes the board bigger and more complicated than I had in mind…

RS485 is probably going to add ~$10, but it would also mean that we’d finally have a proper field bus.

MAX483/MAX485: ~1,50€ ea
ATTiny: ~1,20€ ea

You are going to need a voltage regulator any way as there is no +5V on the extender and that will be a problem when you go up to 24V if the whole combo consumes a bit more than 100mA as it will have to dissipate almost 3/4W which on a small device it may be challenging.

I think I2C will cut it, but it is definitely not the best alternative.

MAX combo + Tiny + regulator + passives + programming header I would say about between $5 and $6 for 100 of.

@F_Malpartida This isn’t intended to use 5V devices that would use very much current. If you wanted to run much current, you wouldn’t want to use a linear regulator, but a microcontroller that’s not sourcing current to other components (like LEDs) and is mostly idle shouldn’t draw much more current than a bright-ish LED.

I was more thinking in the lines of: if you breakout an i2c it would be nice to drop in the pin out a 5V rail. That way you avoid having a local regulator on board. At the end something to power a logic level device.
For the processor I agree that it shouldn’t go above 50mA with all the stuff on it.
Perhaps the best approach may be to mark them as COMs or IOs.

The Robotis servos use a serial bus and it works out really well in practice.


On top of it is an addressable packet based CRC protocol. If you scroll down to “Control Table” you can see what they implement with it for the servo domain.

@Billy Hmm, looks a lot like a 1-wire implementation. That’s another protocol I considered using, but the microcontrollers don’t support it natively and the EEPROMS that I wanted to use with it cost 10x as much as the I2C ones.

The transport is UART and LOTS of uC have multiple UART and the protocol itself is trivial to implement. Combined with a control table it makes it very easy to interact with from within a firmware too.

If you have a uC on the filament drive then it can talk I2C to the EEPROM.