Extruder thermal control board

For a while now I had this idea – create a small board which controls the extruder heaters and fans.

Why – you ask? Well hear my theory. I have this old printer – the RigidBot. It has dual extruder – all direct drive. However I noticed that when it starts to work my temperature readings become very noisy.

Initially I was puzzled, why the noise. After some investigation I noticed that the noise is present only after the printer motors are on. If I switch the motors off (via G-code command) the temperature line in OctoPrint becomes smooth again. It turns out the motor current is creating EMF interference with the thermisor wire.

So I was thinking instead of routing all these wires back and forth, I can build a small board with a cheap CPU that controls the temperature. I can also outsource the control of the cooling fans and even add local display etc.

All the wires needed would be power and some way to communicate between the main board and the extruder daughter board. Audio cables are relatively cheap and well shielded – I can use one for I2C or Serial communication.

In a dual extruder setup one can save quite a bit of wires: two pairs of power wires for the heaters, two pairs for the thermistors, another two pairs for the extruder fans and one or two pairs for parts cooling fans. All these could be replaced with one pair for power and an audio cable for communication – the rest of the wires are all local to the board. Well one has to mount the board somewhere close to the hotends.

Long story short, the first version of the board was not a grand success. The power supply was very noisy and the temperature readings from the ADC were so unreliable, that it was throwing the PID into a weird loop.

Here is the second installment of the board. The power is now dual stage – a buck converter to 5V and then LDO to 3.3V for the micro controller. The LDO filters the noise from the buck converter.

The brain is STM32F030 micro controller. There are 3 fan connectors with tachometer inputs, so in theory the board can alarm if the fan stops working, just like the Prusa MK3. There are 2 thermistor inputs, 2 heater MOSFETS as well as 2 thermocouple controller inputs – for MAX31855 or MAX31865 or similar.

In the next version the voltage the fans would be select-able to whatever the input is (12V or 24V) or 5V. There is a bunch of unpopulated extension pins and an LCD connector for extra fanciness.

I was testing the PID in Arduino code and it works quite well this time.

Just for fun I decided to try my thermal camera to see if there are any hot spots. The picture is with the heater 1 working.

No surprises, the heater MOSFET is a bit warm. The hottest spot is on the buck converter – 37C. Don’t be alarmed by the bright colors 37C is barely warm to the touch.

I’m still trying to figure out what should I use as software platform. Arduino is simple, but somewhat limiting. The STM32 CumeMX is another option. There is MBed and FreeRTOS options if I want to try multi tasking. Oh decisions, decisions.

~V

The TMC2660 board was a bust

I dusted off my trusty pick and place and made one of the newly received TMC2660 driver boards.

Since it’s the first time I test this setup I populated only one of the driver chips – the X axis.

Alas it was all in vain. After fighting with it for several days, the motor would not spin properly. Either my stepper driver configuration so completely busted (although I double and triple checked) or the driver chip is fried. One of the phases works, but the other sends no current to the stepper motor.

Also I was trying to fit some automotive fuses on the board – you know for protection. Alas the fuse holders I ordered are very flimsy and don’t fit the fuses at all. Ordered a different set, but have to wait.

Bummer 🙁

Completed redesign of the TMC2660 branch

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.

Controller brain – replaced

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:

Tested LCD interface

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:

 

Enclosure for the PRNTR board in OnShape

I finally got annoyed enough by the mess of cables and decided to finish an enclosure for the PRNTR board. I finished designing the bottom half.

This is what it looks like in the OnShape assembly:

View from another angle:

Closeup of the final assembly – the outer fan duct:

A look over the whole board:

And finally this is what it looks like, when powered up:

All 3D component designs are available in OhShape here.

More progress on the Smoothieware for STM32

After a few unsuccessful attempts, I got Smoothie to move my stepper motors on the PrntrBoard controller.

At first the smoothie had a bug in the SPI dirver and was unable to talk to the TMC2130 chips. Fixed that, then the steppers still would not move.

I can see the drivers were sending current, because my power supply would start the fans up, but zero steps. I spend the day trying to diff the configuration between Marlin and Smoothie, but nothing was wrong. Finally caught a bug in the Stepper timers and lo and behold movement.

I’ll make a video of my Rigidbot running Smoothie on STM32 next week.

TMC2130 catches fire

A co-worker shared this story yesterday with me. He upgraded his printer to TMC2130 drivers and while he was testing how the new toys performed he got a message that one of the drivers overheated and then the driver exploded in a non trivial ball of fire.

I asked if I can have the driver for some pictures. The driver boards were clones from the usual Asian markets. He now has ordered some “legit” boards from DigiKey. Crossing fingers these would not burn his house down. Said unfortunate driver was on his Z axis and he was running it at 1.1 amps.

This is what it looks like, next to a working board from the same supplier:

(click on the image for better resolution)

As you can see the top of the board kind of exploded, with some of the copper traces melted away. I suspect when the driver overheated either a solder joint shorted or the board shorted internally and that caused the severe failure.

This is the bottom of the board, where the driver chip is mounted:

The damage looks less severe from the bottom. There are charred components, but no melted copper.

Here is the top part – where the copper melted under my microscope:

Another angle – close to the edge of the board:

This is the bottom side – you can see the chip is a bit burned and some capacitors have been barbecued.

Another view of the barbecue area:

The rest of the chip looks intact:

I removed the chip an this is a view of the PCB underneath:

All but 3 pads look in very good condition. Unfortunately the 3 pads have evaporated completely from the board as well as the chip itself:

I was wondering if the chip can be salvaged, but it does not appear to be within my abilities.

One more reason to keep a fire extinguisher handy and not let your 3D printer unattended.

PrntrBoard TMC2130 redesign is complete

When I was working on the new layout for the TMC2660 branch of the board, I used a dedicated ground plane and turned out this was awesome. It simplified lots of the routing as well as added good heat dissipation capabilities to the board.

I wanted to try and redo the layout of the TMC2130 branch with this technique. In addition I wanted to swap the location of the E1 motor driver and the 5V input connector, before the E1 driver was crammed in the corner and it was challenging to get good routing of the power pins. By swapping the position with the 5V power connector there is a bit more space.

The third thing I wanted to try was to reverse the position of the STM32 NUCLEO board – in the previous design it was sticking out in an unsightly manner.

So here it is new layout all complete. DRC checks pass.

In a slightly different perspective:

You can see the NUCLEO does not block the mounting hole on the lower left corner anymore (MK4).

Here is a look from the bottom:

The motor driver have large area on the bottom for heat dissipation. You can also see the large rectangle area on the bed heater control MOSFET on the top.

I also added a few extra power connectors – two for Vin and two to the 5V rail, to hook cooling fans for the case. You can see two of them on the low left corner in the last picture.

Note: while the last picture shows the STM32F411 CPU, the board actually required the STM32F446 version. The only 3D model I found for the NUCLEO STM32 dev kit was with the STM32F441 part, so that is why it is on the images.