Wednesday, January 29, 2020

Setting up TMC2209 in UART mode on MRR ESPA

Note: This post is specifically for the MRR ESPA and MRR ESPE boards. While the principle may be similar, it is not guaranteed to work for other boards. Please consult your manufacturer for support. Also, this post was written in January 2020 and may not apply to the latest version of Marlin.

The MRR ESPA is a 3D printer control board based on the ESP32 microcontroller. Marlin 2.0 now has support for ESP3D web interface on the ESP32, which means that 3D printers controlled by ESP32 can run Marlin with a tested web interface.

However, one of the issues with the ESP32 is the lack of GPIO pins. And given that each TMC2208 stepper driver needs 2 pins (RX + TX) to run in UART mode, I decided not to design jumpers for configuring TMC2208 drivers. Instead, only jumper configuration for TMC2130 in SPI mode was added.

But the new TMC2209 driver allows configuration of a slave address (up to 4 separate addresses) for each driver. What this means is that up to 4 x TMC2209 drivers can share a single set of RX/TX serial port. And the ESP32 has 3 hardware serial ports (one is used for the USB, which leaves another two unused) so technically, the MRR ESPA should be able to support 4 x TMC2209 stepper drivers in UART mode if slave addresses are used.

For those who don't like to read, you can watch this simple video, but I think reading the blog post should give more information.


Preparation
- Remove the DIAG and INDEX pins on the TMC2209 driver. Use a soldering iron, put it between the two pins to melt the solder of both pins together, then pull out both pins from the other side.
- Make the cable required to connect the serial port (RX and TX) to the PDN pin on the TMC2209.
- Make the cable to connect CLK on the TMC2209 to GND. The TMC2209 allows the use of an external clock signal, and the CLK pin should be connected to GND if the external clock is not used. This is basically a split wire, with a single wire being split into as many ends as needed (depends on number of stepper drivers using TMC2209). Update: After a close look at the TMC2209 schematic, there is no need for the cable to connect CLK pin to GND.

Preparing the firmware
- In Configuration.h, set the driver type for each axis using TMC2209. For example:
  #define X_DRIVER_TYPE  TMC2209
  #define Y_DRIVER_TYPE  TMC2209
  #define Z_DRIVER_TYPE  TMC2209
  #define E0_DRIVER_TYPE  TMC2209
- Also in Configuration.h, you can switch the motor direction. For example:
  #define INVERT_X_DIR true
  to
  #define INVERT_X_DIR false
  Do this for each axis using TMC2209. This is optional. You can also just flip the motor connector around, which is what I usually do.
- In Configuration_adv.h, configure the slave addresses. For example:
  #define  X_SLAVE_ADDRESS 0
  #define  Y_SLAVE_ADDRESS 1
  #define  Z_SLAVE_ADDRESS 2
  #define  E0_SLAVE_ADDRESS 3
- Also in Configuration_adv.h, set up the serial port to use by adding the below (just below the slave addresses):
  #define X_HARDWARE_SERIAL Serial1
  #define Y_HARDWARE_SERIAL Serial1
  #define Z_HARDWARE_SERIAL Serial1
  #define E0_HARDWARE_SERIAL Serial1
  This tells Marlin that the TMC2209 on X, Y, Z, and E0 are using the second hardware serial port Serial1. (Update 2020/2/22: Marlin has some issues recognizing hardware serial defines for extruders. See this issue on how it can be worked around.)
- Finally, also in Configuration_adv.h, set up the serial port parameters to use by adding the below (just below the slave addresses and the ?_HARDWARE_SERIAL lines):
  #define TMC_BAUD_RATE 115200, SERIAL_8N1, 21, 22
  This sets the serial port(s) for TMC UART mode to run at a baud rate of 115200, 8N1 protocol, and use GPIO21 for RX, and GPIO22 for TX. It is a quick and dirty hack that only works if one hardware serial port (which supports up to 4 x TMC2209 drivers) is used.
- Done! Build the firmware, then flash it to the board via USB or OTA. (Note: In Configuration_adv.h, there are many other options for Trinamic drivers. You can read the comments for more information.)

Installing the stepper drivers
- Remove all jumpers for the stepper motors (MS1, MS2, MS3, RST). The RST/SLP jumper is totally not used. MS1 and MS2 will be used to set the slave address (next step). MS3 jumper can be used, but this is a bit difficult to explain and I will do so separately.

- Use MS1 and MS2 to set the slave address for each axis that will be using TMC2209.
  Address 0: MS1 and MS2 unconnected
  Address 1: MS1 connected to VCC, MS2 unconnected
  Address 2: MS1 unconnected, MS2 connected to VCC
  Address 3: MS1 and MS2 connected to VCC
  The photo below shows slave addresses configured as X=0, Y=1, Z=2, E0=3.

- Connect the PDN cable. The wire with a 1K resistor should be connected to the pin being used for TX. For the MRR ESPA in this example, this would probably be GPIO22, which is labeled SCL. The other wire is for RX, which is GPIO21 labeled SDA on the board. The remaining wires connect to the PDN pin on the TMC2209. (Note: Check your TMC2209 schematic to see which is the PDN pin. For the BIGTREETECH TMC2209 V1.2 driver that I am using, it is in the same row as the EN pin, pin number 4 in that row with pin 1 being the EN pin. If PDN is on pin4, then MS3 jumper can be used to route the PDN pin to the CS_PIN header. See further below for how to use this.)
- Connect the CLK pins on the TMC2209 to GND on the MRR ESPA using the other cable that was prepared.

- Finally, connect the motors, then power up the board!

After powering up the board, sending M122 via serial terminal should give the status of the drivers if TMC_DEBUG was enabled.

For the MRR ESPE, the process should be similar. However, unused pins like GPIO2 and GPIO4 can also be used for the third hardware serial to support the 5th stepper driver on the MRR ESPE. This requires a bit more work to set up the third hardware serial port Serial2 to use those pins, though. For example, something like the below line will need to be added somewhere
  Serial2.begin(115200, SERIAL_8N1, 2, 4);
(Untested because I don't have enough TMC2209 drivers.)

Okay, a bit about MS3. If the MS3 jumper is connected to the "TMC" side, it will route the MS3 pin (which is the same position as the PDN pin on my TMC2209 driver board) to the respective CS_PIN on the board. This means the RX/TX/PDN cable can be connected to the CS_PIN header instead. This is especially helpful if the PDN pin is not exposed to the top side of the stepper driver board.

For more information on the MRR ESPA:
Facebook page
Facebook group for users
GitHub repository
MRR ESPA available here
 
Note (added January 23, 2021): I found that someone has actually posted the design of the MRR ESPE in his name on PCBWay. This is the page. Whoever this Oleg person is, he is in no way related to me nor this project and does not have the rights to post the design on PCBWay. I made the project open source but open source is not free, and it definitely does not mean you can take credit for something you did not create. It means you can use it if you give proper credit to the creators of the work.

Sunday, January 26, 2020

Useful links for setting up 3D printers

Setting Up a CoreXY Printer's Origin and EndStops

Just a blog post for my own reference. The above link helped me when setting up the endstops and motors for a coreXY printer (my modified FLSun Cube) and I always refer people to it when they have issues with endstops on their coreXY setups.

Don’t trust the internet (and how to add an Inductive Proximity Sensor to your 3D printer the proper and easiest way)

This post talks about the various ways of getting an inductive probe running on 6-36V to work on 5V logic using either a voltage divider or a diode. The principles work for 3.3V logic too, and the diode solution was adopted for the MRR ESPx boards.

Saturday, January 25, 2020

Happy Lunar New Year!

Happy Lunar New Year!

This is the Year of the Rat. The start of a new 12-year cycle.

All the best to everyone!

Thursday, January 23, 2020

A short history of Marlin development for the ESP32

As far as I know, Marlin development for the ESP32 started in May 2017 with Simon Jouet. Here, I am talking about the development of an ESP32 HAL for Marlin; although Luc Lebosse seemed to have started work on supporting ESP32 on ESP3D webUI around the same time.
https://github.com/MarlinFirmware/Marlin/issues/6524
https://github.com/luc-github/ESP3D/issues/118

Simon Jouet worked on the ESP32 HAL in parallel with his ESPRamps. This then became the R1 prototype of his ESP32Controller. In mid 2018, the HAL was more or less developed to the stage when it can pull off a test print. Simon's brother, Hadrien Jouet, did up a simple web interface for use with Marlin. At the same time, Luc Lebosse had been working to merge Marlin with his ESP3D webUI, so that Marlin can run on an ESP32 that also works as a webserver that serves out the ESP3D webUI. Toward the later half of 2018, I started work on developing a 3D printer control board based on the ESP32, which eventually became the MRR ESPA. (For the history of the MRR ESPA, please see this post for links to the individual posts.)

In December 2018, an idea was floated to use the ESP32's I2S as a form of output expander to address the shortage of pins on the ESP32. This feature made its way into the ESP32 HAL in the first months of 2019, and also saw Simon Jouet's R2 prototype of his ESP32Controller. I2S can now be used to driver stepper motors by daisy-chaining 74HC595 (each of them provides up to 8 outputs; daisy-chaining 4 of them will give 32 additional outputs). To avoid confusion with the native ESP32 pins, output pins based on the I2S stream are numbered starting from 128.

The rest of 2019 saw quite some work on the ESP32 HAL by the open source community. This included further modifications to allow the I2S stream to provide PWM output so that it can be used to control heating elements and fans. This also led me to create the MRR ESPE board based on the MRR ESPA but with I2S added. Improvements were made to make the HAL more stable, and Luc Lebosse actively kept his fork of Marlin (which supported his ESP3D) up to date with the main Marlin repository.

In January 2020, Luc Lebosse's integration of ESP3D into Marlin was merged into Marlin 2.0. This means that users of stock Marlin can now use the ESP3D webUI on any ESP32-based boards. There is no longer a need to use a custom fork; ESP3D integration is provided via the ESP3DLib library.

This is a short history of the development of the ESP32 HAL on Marlin so far. I hope this helps to give some background, and I also hope others will continue to work on using ESP32 for 3D printing.

My new workflow for updating Marlin configuration files

In the past, I used to update my Marlin configuration files manually. Open up the configuration files in a text editor, and go through them line by line. This was tedious because Marlin is under active development, and the configuration files do change from time to time.

Then I came upon Meld, which helps to significantly ease the comparison between newer versions of the configuration files and what I have already configured by hand. I still need to fetch the latest updates to the Marlin repository, then run Meld. It is a cycle of
git stash
git pull
and then Meld. Because I have a few sets of configuration files, I ended up maintaining several copies of Marlin, one for each set of configuration files.

Recently, I started using GitHub Desktop (I had known its existence for a while, but never got down to using it). And it really made my life so much easier.

The new workflow?

  • Use GitHub Desktop to discard all changes.
  • Pull changes from the main Marlin repository. These can be done with mouse clicks instead of using the terminal.
  • Run Meld to make changes to the new version of the configuration files. At the same time, use Meld to update my old configuration files (which I store away in a separate directory). At the end of the process, the two sets of configuration files would be identical. Basically, a two-way merge.
  • Save the files.
  • Compile in VSCode.
  • Copy firmware.bin to another directory, and rename it so that I know what it was compiled for. This file will be uploaded to my printer at another time via OTA using the webUI.
  • Repeat the process for the other sets of configuration files that I have.


Background: The reason why this process of updating configuration files is tedious for me is because I have at least four sets of configuration files:

  1. MRR ESPA (native pins only) board for Ender-3
  2. MRR ESPE (I2S) board for Ender-3
  3. MRR ESPA (native pins only) board for coreXY modified FLSun Cube
  4. MRR ESPE (I2S) board for coreXY modified FLSun Cube
For Linux users, a version of GitHub Desktop for Linux can be found here. Available as rpm, deb, or it can also be installed via snap.

Tuesday, January 21, 2020

Darkness and Alice, the (almost) same blonde knights

I am not a big fan of anime, though I do watch some.

And thus, I kind of saw some familiarity between Darkness from Konosuba (『このすばらしいせかいにしゅくふくを』), and Alice Zuberg (or more correctly, Integrity Knight Alice Synthesis Thirty) from Sword Art Online: Alicization.

Darkness:

Alice:


Both of them are knights (technically, Darkness is a crusader) wearing plate armour. Both have long blonde hair. Both want to protect people (as knights do). And even the way they talk seemed to be similar... and that was when a bit of searching on Wikipedia showed that they are both voiced by the same voice actor, Kayano Ai. Talk about recurring stereotypes in Japanese anime...

Still, appearances can be deceiving, and I guess the similarities between Darkness and Alice are only skin deep, since they do have different personalities.

Monday, January 20, 2020

The history of MRR ESPA (links)

The MRR ESPA is a 3D printer control board based on the ESP32 micrcontroller. It runs Marlin firmware, and works best with the custom fork of Marlin that supports the ESP3D web interface. Below are links to the individual posts about how the board was developed.

In the beginning
Custom Marlin fork
Toward a stable design
Ready for launch

For more information on the MRR ESPA:
Facebook page
Facebook group for users
GitHub repository
MRR ESPA available here

Tuesday, January 14, 2020

Issue with SD file uploads and MONITOR_DRIVER_STATUS feature

It seems that the MONITOR_DRIVER_STATUS feature in Marlin (found in Configuration_adv.h, and used for monitoring Trinamic stepper drivers) will affect SD file uploads.

This is likely because the SD card shares the same SPI as the Trinamic TMC2130 stepper drivers which I am using. With this feature enabled, my SD file uploads kept having problems. The uploaded files were never the same size as the originals (although very small files uploaded without problems), and disabling this feature allowed me to upload files of up to 30MB at full SPI speed without any issue.

So I am posting this in case others are having the same issue.

I arrived at this solution because I noticed the following errors over serial terminal:
00:00: X driver overtemperature warning! (650mA)
00:00: Y driver overtemperature warning! (700mA)
echo:Upload failed

I have TMC2130 drivers in SPI mode for my X and Y axes, and the current setting for X at 650mA, and Y at 700mA. However, I was not running anything on my printer except trying to upload a file, so this overtemperature warning made me think it could be some issue with the sharing of the same SPI between TMC2130 and the SD card. A bit of searching around past Marlin issues didn't give the exact problem, but suggests that MONITOR_DRIVER_STATUS may be causing problems. When I disabled MONITOR_DRIVER_STATUS, the SD file upload issues went away.

Update (2020/1/20): Pull request Sanity check for TMC+SD shared SPI has been merged into bugfix-2.0.x. This sanity check throws an error if MONITOR_DRIVER_STATUS and SDSUPPORT are both enabled, telling the user that they cannot be enabled together.

Saturday, January 11, 2020

U.S. refuses Iraq's request to remove troops

Washington turns down Iraqi call to remove troops

This is... just bad news for our current international system built on national sovereignty.

More than 100 years ago, China faced the same thing. Countries were stationing their troops on Chinese soil under the name of "protecting our nationals". There is no question about countries protecting their own embassies overseas; embassies are considered sovereign, which is why countries can and do station troops on embassy grounds. But to station troops somewhere else, that is different. Such deployments are usually in agreement with the host country (like Japan and South Korea), and to do otherwise is to undermine the respect for national sovereignty that has formed the foundation of our current international system.

If the U.S. can station troops in Iraq to protect its embassy, even if Iraq does not welcome such a deployment, then there is nothing stopping China from doing similar military deployments to protect its national interests overseas against the will of other sovereign countries.

Which part of "refusing to leave" does not make the U.S. an occupying force?

Which part of "refusing to leave" is not a slap in the face to all countries who want to uphold the rule of national sovereignty?

Which part of "refusing to leave" is not undermining our current international system?

Why, U.S.? Why? We used to respect and honour you for being the big champion of the rule of law, of being the protector of our international system. Why are you undermining all that now?

Friday, January 10, 2020

Law enforcement and military response in the U.S.

Just a random thought. It seems that the U.S. handles military response like its law enforcement.

Police: "He was arrested for resisting arrest."
Reporter: "What was he resisting arrest for?"
Police: "It doesn't matter. He was arrested for resisting arrest."

U.S.: "We are responding with military force because they hit at U.S. military installations and personnel."
Media: "Why did they attack U.S. military installations and personnel?"
U.S.: "It doesn't matter. They attacked us."

😶

Random thought. Don't hit me.

Wednesday, January 01, 2020

Happy New Year 2020!

Happy New Year!
May 2020 be a great year for everyone!


This year, we decided to keep things small-scale. 😉