I spent a lot of time getting the PrntrBoard tmc2130 version to work. I’m at the point where I’m quite happy with it and don’t see major further changes. The tmc2660 branch did not get a lot of attention in the mean time.
So I spent a weekend completely re-designing the tmc2660 board. I ported all changes from the tmc2130 version. There is now a dedicated ground plane layer and routing it much easier.
I opted to put all drivers on one side of the board. Unfortunately limiting the size to 10x10cm (or 3.9×3.9 inches), I could not fit all drivers in one row. Hopefully cooling would not be major PITA as it was on the tmc2130 version.
Here is a screenshot of the 3D rendering of the redesigned board:
Please excuse my mistake, the top row of power connectors is facing backwards. Fortunately these are symmetrical and I can simply solder them the other way.
Here is a view from the top:
I used very aggressive layout for the connectors and I ended with some spare space in the middle of the board. I was thinking to add two automotive type fuse holders for extra protection. I haven’t quite settled on what fuse holder to use. Here are two renderings with the footprints in KiCAD:
And view from the top:
All changes have been pushed to my GitHub design repository page. The version with the fuses is in the tmc2660-fuse branch.
While I was working on porting Smoothieware to run on my 3D printer controller, I was going back and forth between my trusted NUCLEO-64 F446 devkit and a new acquisition from china – the “Black VET6“. That was a very capable board with onboard SPI EEPROM, battery backup, micro SD card and USB connector – all this for less that $10 from aliexpress.
While the NUCLEO has the advantage of build-in ST-LINK debugger, I was missing the SD-CARD connector and the extra pins to work with.
The NUCLEO-64 uses only 64-pin micro-controller package and I was running out of available IO pins. For example on the Rev3 of my controller I has to use every last pin to be able to connect an LCD screen – and even then sharing the SPI bus between the screen and the TMC drivers was causing some issues.
Here comes a proposed solution for this issues: a NUCLEO-64 form factor board designed with a 100-pin MCU (STM32F407VE):
This was my very first try and I did not have all parts available yet, so you can see some unpopulated pads.
The board is the same size as NUCLEO-64, and has the same dual row connector on the back:
Here is a “fuzzy” picture of the two boards side by side:
The USB connector is micro-usb, which I think is more available. There is a micro-sd card slot and a plethora of expansion ports for future extensions like LCD panel, WiFi module or even more extruders.
I also added some SPI EEPROM so we can save settings etc. Last but not least there is a power supply module which provides 5V up to 3A from 12 to 24V input. The 5V and 3.3V from the CPU board are connected to the motor controller board so there is no need for an external 5V buck converter anymore.
The only slight disadvantage is that now I have to use external ST-LINK adapter to program the board and an external serial-to-usb adapter for debugging.
Here is a little video comparing the two boards side by side:
I had one RAMPS discount full graphics controller laying around from my RigidBot. I did use it with the original controller and decided to test it with the PrntrBoard.
In Rev1 and Rev2 of the board I did not have enough pins on the LCD connector to be able to use all buttons on the panel. In the Rev3 I used every last pin of the tiny 64-pin package and I just got enough (or so I thought).
I learned the SPI used by the LCD panel is not very standard and had to fight with Marlin to make the TMC drivers and the LCD co-exist on the same SPI bus.
Finally I was able to use the panel:
One of the pins I used for the button input did not quite cooperate, so I have only one button + the rotary controller for the UI. Lucky for me both Marlin and Smoothieware were functioning with that configuration.
I had to disable the TMC diver monitoring, because the LCD controller was getting confused by the SPI communication with the TMC drivers. I think I can create a small breakout board with a few AND gates to alleviate this interference.
Here is a video of the panel working in Smoothieware: