Update Feb 10, 2019: "Blue screen of death" solved. Somehow, the BTN_EN1 (which is connected to GPIO0) pin was pulled to GND. This caused the board to go into flash/download mode. I turned the rotary encoder on the LCD a bit, it somehow cleared the GND status of the pin, and the board could boot with the screen working fine.
About two weeks ago, my "clone" CR10 stock display (the LCD controller with EXP3 for Creality printers) died on me with a blue screen. When I powered on the printer (my coreXY modified FLSun Cube with the MRR ESPE board), the LCD screen shows a blank screen (blueish back light), and the printer does not boot up properly. I cannot access the printer via WiFi too. When the LCD is disconnected, the printer can be accessed via WiFi, so I know the issue is with the LCD.
Today, the same thing happened on my Ender-3 (running on a MRR ESPE too). Same thing, blue screen on the stock LCD and the printer fails to boot. Disconnect the LCD and the printer can boot up and become accessible via WiFi. Right now, it is even doing a print controlled via the web interface.
I haven't went into troubleshooting the LCD yet, but if anyone has any suggestions on where to start looking, I am all ears.
The rule of law. This is made to sound like a Western (European) concept, a concept that is unique to free democracies as modeled on Western thought. But laws have existed for millennia. The rule of law is not unique to the West.
What differs is the concept of law. Here, I will use two broad opposites, the East and the West, to give a broad overview of the differences. East is the sphere of influence that imperial China had, covering mainly East Asia and where Confucianism had heavy cultural influences. West is mainly Europe and parts of the Mediterranean that have developed with heavy influence from monotheistic religions.
My ideas are probably not new. They stem from what I have read, like Ruth Benedict's The Sword and the Chrysanthemum, and works by Wang Gungwu. Concepts like shame vs sin, and how China sees the rule of law.
First, the West. Law is sacrosanct because laws are ultimately derived from the covenant between man and God. The most basic of laws, the moral and ethical code, has a divine origin. This is then further codified by man into a more detailed set of laws, but they ultimately draw legitimacy from the divine, from something greater than man. It is about sin and how sin keeps people's actions in check even when no one else is looking, because God is always looking. Laws are therefore something to be held in high regard and strict adherence, since the first laws were cast in stone.
Contrast that with the East, where moral and ethical codes were not passed down in stone from a divine being, but come from various great philosophers like Confucius and Laozi who have their own preachings about how people should live. There was also the contest in ancient Chinese schools of thought between governing through moral codes versus governing through written ones. In the end, the Chinese arrived at governing using both. Moral codes and written laws are used to shape people's behaviors, but both are man-made. Man came up with them, and man can and do change them to suit the times.
In the West, the respect for the law has divine roots. In the East, the respect for the law varies with the power wielded by those who enforce the law.
When viewed through such a lens, China's actions whenever it challenges the existing international system may seem to Western eyes like a disrespect for the rule of law. But when viewed from an Eastern perspective, China is not disrespecting the rule of law; rather, it is challenging the appropriateness of the current set of laws. To China, laws are man-made, and they can and should be changed according to the times and circumstances. Since a set of laws is respected and observed only when there is some authority willing to enforce and uphold those laws, China is also challenging the will of nations to enforce and uphold the current international system.
If so, the key to getting China to keep within our current system is to show commitment toward enforcing and upholding what we have. But this also means we have to relook at our current system, and ask ourselves, "What are we willing to defend? What are we ready to change?" Because we can try to hang onto old and obsolete rules, but it is going to be hard to convince people to defend them. When our systems are always in line with the times, people will feel more willing to enforce, defend, and uphold them.
At a time when China is doing its best to fight the coronavirus and contain its spread, such articles like the one linked above do not help. China knows the economic impact to its own economy from the steps it has taken to stop the spread. Imagine if China had decided to prioritize its economy over containing the spread.
Also, while the article talks about companies switching to suppliers in other countries, any reader with some common sense will recognize the scale difference between China and these other countries. These other countries will not be able to replace China; they can serve as temporary replacements in the short term, but a lot more will need to be done to allow these countries to significantly increase production capacity to be able to replace China in any significant manner. So making it sound like China is going to be replaced because of this virus is just... playing to feelings instead of showing the facts.
The issue of short-term production capacity also serves as a further limit on just how much companies can do to switch to replacements in the supply chain. Yes, any production plant with a proper manager will have some spare capacity on hand. But such spare capacity is limited, and usually unsustainable. For increase production over longer periods of time, capital investment is needed. More labor is needed. It will take time to buy/build equipment, and the labor market imposes a limit to the extent that companies can hire to increase production.
And finally, any company worth anything would have in place a business continuity plan to handle contingencies like a problem with a supplier. This means a certain amount of inventory on hand, stockpiles of parts, and short-term alternatives. This plan should buy them enough time to work out other arrangements for the short-term and maybe even medium-term.
Anyway, it seems workers in China are starting to get back to work. Maybe there will be a short-term decrease in production output because not every worker can get back to work in time, due to quarantine and transportation issues. But if anything, this is a people which has survived several millennia of disasters. Let's have some confidence in them, and give them due credit for taking the steps to help contain the spread.
Recently, I have been experiencing a lot of layer shifts on my 3D prints. So I am writing this post more to document what was done to solve the layer shift issue.
Just some background. The printer in question is an Ender-3, running a Titan Aero direct drive. It uses the MRR ESPE board with TMC2130 drivers on X and Y axes. The firmware used is Marlin bugfix-2.0.x.
I started to get layer shifts toward the end of last year when I started to test out Marlin bugfix-2.0.x integrated with ESP3DLib. So my first suspect was the newer versions of Marlin.
It turns out Marlin now enables junction deviation by default, while my slicer settings are more tuned for classic acceleration and jerk control. I was not very sure how junction deviation would affect my prints, but to be safe, I turned that off by enabling classic jerk control.
But that did not solve the layer shifts. So I thought, could it be the motor current that I set for X and Y axes? At 800mA for both X and Y (the default in Configuration_adv.h), my motors can get quite hot to the touch. So I lowered them to various values, and eventually settled on 600mA. (See explanation further below).
Yet that did not help much, although I seem to have limited layer shifts to the X axis only. So I checked my belts, and realized the X motor belt was a bit loose. So I tried my best to tighten it, and managed to get a decent print.
Time to add those belt tensioners to the X and Y axes, or at least the X axis.
More about motor current. On A4988 stepper drivers, the Vref allows setting of max current. This should be below the rated current of the motor, and a good recommendation is 80% of the rated current. However, on TMC2130, it seems the motor current setting is for setting RMS current. Which is peak current divided by 1.41. So if the max current is 1.0A, and you want to run at 80%, which means a peak current of 0.8A, the RMS current should be 0.567A.
On the Ender-3, after quite a bit of Googling around, it seems to suggest that the motors I have for X and Y are only rated for 0.9A! A setting of 800mA on the default firmware settings would give a peak current of 1.128A, which was probably why my motors were running hot. I ended up setting it at 600mA, which gives a peak current of 846mA. That is below the rated 900mA, but still more than the 80%. However, I thought I needed that extra juice because of the heavy bed on Y axis, and the heavier X gantry due to the direct drive setup. For those interested, my X and Y motors have "BJ42D15-26V02" on them, and should correspond to Creality3D's 42-34 stepper motors.
BTW, on Chinese A4988 drivers, the Rsense value is usually 0.1 ohm instead of the 0.05 ohm on original Watterott drivers. A quite and easy way to determine Vref for Chinese A4988 drivers is to multiply the peak current by 0.8. So if you want a peak current of 0.8A, you should set Vref to 0.64V. Be sure to check your Rsense value; a Vref of 0.64V will give a peak current of 1.6V if the Rsense value is 0.05 ohms!
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.
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.
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.
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.
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.
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:
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.
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.
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.
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?
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."
Please leave a comment if you are interested in commissioning a piece of calligraphy or want to purchase any of the calligraphy works I have posted on this blog.
