How to build the SMuFF-Backbone

What I also took into consideration is that the PCB must to fit into the existing housing. I myself wouldn't be very happy if I had to print a new housing just for that, and hence I guess you wouldn't be either.

As you can see in the picture above, I've accomplished this goal too.

Before you start...

Take a closer look at the SMuFF-Backbone PCB. Front and backside will provide you extensive silkscreen labels that distinguish the various components from each other, as well as the various integrated modules. The backside in particular contains valuable signal designations, that are important  when wiring the board.

Design flaws discovered

The first small design flaw I found was in the interface to the controller board. The SMuFF-Backbone uses the I2C interface for communication, but since I2C connectors are rare on most of the 3D printer controller boards  (i.e. on some non existent) I had to come up with a solution that would work with most of the (newer) boards. This solution is the Z-Probe header, which I've used to set up a software I2C port.
This header has all the signals needed: Power, GND and two spare GPIO pins, which are usually being used as the Probe deploy output signal and the probe trigger input signal.
Though, being GPIO (a.k.a. General Purpose Input/Output) pins, one can use those for whatever function is needed. In my case, I've set them up to mimic the SCL and SDA signals used in a I2C communication.

However, I mistakenly assumed that the Power is running on 3.3V (because of the default logic levels on a modern STM32 MCU)  whereas in reality this pin on the Z-Probe header is connected to the 5V rail. That's not a biggy, since most of the I2C devices are pretty much tolerant in terms of power input and will work with either 3.3V and 5V.
Though, I've also added two "outgoing" I2C headers to the SMuFF-Backbone (J2 and J9), one of which (J9) can be configured to output either 3.3V or 5V, depending to how JP6 is bridged. In case of  the 5V bridging, the I2C would get the power from the on-board Buck converter, in the other case from the power pin connected to the controller board (which was supposed to be 3.3V but is 5V).
This means, that in the worst case the I2C header J9 will deliver always 5V, regardless how JP6 is bridged, as long as the input comes from the Z-Probe header (see pictures down below).  

This all still may not matter because of the said voltage tolerance of I2C devices, unless one plans using the Wemos D1 mini as the Remote control option. Some of the input pins on the Wemos board are directly connected to some of the SMuFF-Backbone output pins, which may kill the input pin driver on the Wemos D1 mini. 

So, to be on the safe side and keep the power output on J9 selectable as intended, the solution is to wire the I2C power pin to the 3.3V pin of the SPI header of the controller board instead of the Z-Probe header PWR pin. 

The next design flaw I discovered concerns the said Wemos D1 mini. Despite the possibly wrong voltage levels on the input pins, I figured that some of the connections / SMD parts aren't needed at all and might even hinder the device from booting up correctly.
The basic idea behind the flawed design was to have the option of updating the firmware from within the SMuFF itself and allow the SMuFF to communicate with this device over I2C. It turned out, OTA updates are much easier to accomplish and faster too. For the communication the serial interface which is supposed to be already connected to the SMuFF  (Serial2/3) does that job even better.

That's again only a minor flaw, that can be fixed easily. Simply don't apply the resistors crossed out on the picture down below (R5, R6, R7) and also don't solder the pins SDA, SCL and RESET to the SMuFF-Backbone (or better yet, cut them off before plugging the Wemos D1 mini into the socket U4).

Hint: If you don't plan on using the Remote Control option at all, simply don't apply and solder any of the SMD/THT components shown in the picture above.
Although, please be aware: If you change your mind at some point later on, it might be a pain to apply those parts afterwards.

Assembling this PCB manually is pretty straight forward. First populate the PCB with the SMD components and solder them (see 1st picture down below) , then move on and apply and solder the THT components, such as sockets, headers, terminals, relays and JST connectors (see 2nd picture down below).

Hint: If you plan adding the Wemos D1 mini (for Remote Control), make sure you use a low profile socket / headers. Those 9 mm standard sockets that usually ship with the device will most probably intersect with the headers of your display. A low profile socket/header (2.5 mm at max.) will save you here.

As for the Buck converter, please notice that the SMuFF-Backbone comes with the option of using two different types: the SY8205 and the MP1584EN boards. The SY8205 will output 5V only, whereas the MP1584EN has to be configured to the 5V needed.
The SY8205 is able to deliver up to 5A of current, whereas the MP1584EN is limited to 3A, which should be decent enough for 2 servos. 

Before you're able to solder the SY8205 onto the SMuFF-Backbone, you'll have to break off the right side with the solder pads. No worries, the board is designed accordingly.

If you go with the MP1584EN board, make sure that the jumper on JP1 is not inserted as you tune in the output voltage via the potentiometer.
Once you've tuned the 5V in successfully, plug a jumper on JP1 and the components on the PCB will come to live (at least the PWR LED is supposed to light up). 

After you have soldered everything to the SMuFF-Backbone PCB, make sure you clean off any solder paste residue using IPA and a soft brush (old toothbrushes turned out to be very useful for this task). 

Wiring it up

Once you've assembled the PCB, it's time to put it into the housing and wire it to the SMuFFs controller board. The picture below shows you, what the wiring is supposed to look like.

As you wire up the power (+12/+24V) that's coming from your PSU and also powers the controller board, double check the polarity. If you accidentally swap it, you will destroy the Buck converter instantly.

I'm not going into more details here, since the wiring is pretty straight forward and the essentials have been already explained above and on other pages of this website (see here and here for example).

Wiring up the Wemos D1 mini is pretty much the same as explained here. This device also uses a TTL-Serial communication, which is being established by wiring the TFT-Serial header (Serial 2) of the controller board to the to SERIAL 2/3 connector on the SMuFF-Backbone.
Please keep in mind: Before you can use this feature, you have to flash the specific firmware and file system onto the device. Both of which can be found here on Github. Once you've set up the device and connected it to your WiFi network, you'll get full access to the SMuFF via the SMuFF-WebInterface.

I2C-Bus Termination

As usual, this board comes with the option of terminating the I2C bus (via two 4.7K resistors). According to the I2C specification, the bus needs to be terminated at its furthest end. Hence, you'll find two solder jumper named JP2 and JP3 right below the J2 header.
As long as you don't have any other I2C components attached to either J2 nor J9, the furthest end of the I2C bus is on the SMuFF-Backbone board. Therefore you have to solder-bridge those jumpers (or bridge them using two 0 Ohm resistors). 

Vice versa, if you do have something attached to J2 or J9, you have to open up those solder jumpers.

If you're uncertain whether or not you'll use one of the features that will make use of the I2C bus, I'd recommend leaving those jumpers open and instead soldering two 4.7K resistors between the signals SDA / VCC and SCL / VCC of J2 onto a DuPont female header. That way, if you plug this contraption onto J2, the I2C bus is terminated as required and in case you extend the I2C bus later on, the termination will be replaced by the cable going to some another I2C device, which hopefully already meets the specification.