Saturday, December 28, 2019

Lessons from MRR ESPA: Heated bed and power

In this post, I will write about the lessons I learnt when designing the MRR ESPA. Specifically, lessons related to the high currents used for the heated bed, which I learnt during the early phase of the design.

1. Separate power connectors for heated bed. Heated beds can draw a lot of current. So using the same power supply for the heated bed and the rest of the 3D printer (control board, motors, hotend, etc.) can result in a very high current being carried from the power supply unit (PSU) and the board. If the power connector on the board is not rated for such high currents, they can melt, burn, and become a fire hazard. This is why some boards are designed with a separate set of power connectors for the heated bed. This allows the same PSU (which usually have a few sets of output leads) to be connected to the board, with one set of output leads for the board and such, while another set of leads for the heated bed. This lowers the current being drawn on each set of leads, keeping temperatures lower.

2. Separate power supply for heated bed. While boards may have separate power connectors for the heated bed, this does not mean they are designed for separate PSUs. To safely use separate PSUs on the same board, the different power rails should be isolated from each other. When an external MOSFET is used for the bed, this MOSFET (like the Little-Driver) usually has an optocoupler that separates the bed PWM signal from the bed supply. In designing the MRR ESPA's heated bed circuit, I included this optocoupler into the design. This separates the bed power supply from the rest of the board, which means separate PSUs can be used on the same board. (Note: There are people who say you can use separate PSUs on the same board as long as the GND of the separate PSUs are tied together to get a common reference. I am not a certified electrician and therefore cannot say how safe this is. I prefer not to take the risk, and use the optocoupler instead since that is a much safer design.)

3. Trace width. High currents need thicker trace widths in order to have sufficient cross-sectional area to carry those currents. Simply put, the larger the current, the larger the cross-sectional area. Otherwise, the resistance in the traces will result in greater heat, and can use the PCB to melt and burn.

4. MOSFET selection. MOSFETs generate heat. While it is more complex, an easy way to calculate the amount of heat generated is to multiply the square of the current being driven by the on-resistance of MOSFET. (This is only one part of the equation, though.) This means that a low on-resistance is preferred for the heated bed MOSFET. But another factor is the thermal resistance, which is basically the temperature rise per watt of power generated. Some packages have 62 degC/W, while some are 50 degC/W. Obviously, the 50 degC/W MOSFET will get less hot when driving the same current. (And I learnt a lesson: Chinese clones of MOSFETs may not always work as expected.)

5. MOSFET cooling. Since MOSFETs generate heat, cooling is required. MOSFETs can usually be cooled by the PCB if there is a large enough "heat sink" area. The thermal resistance on data sheets usually state what that "heat sink" area is when they tested the MOSFET. If your board does not have a sufficient "heat sink" area to help cool the MOSFET, the thermal resistance will be significantly less than what is stated on the data sheet. This is why the bed MOSFET on the MRR ESPA has such a large copper area exposed on the reverse side of the board.

6. MOSFET gate voltage. MOSFETs usually have a range on-resistance that gets lower as the gate voltage increases. This is why it I designed the MRR ESPA with a jumper that controls the voltage used to drive the optocoupler that is connected to the MOSFET's gate. This optocoupler should use 12V if VBED is 12V so that the bed MOSFET can be driven with a high gate voltage. But if VBED is 24V, the optocoupler needs to be driven at a lower voltage since the maximum gate voltage is 20V. The jumper is based a connection to a voltage divider to divide the voltage by half; on a 24V VBED, this means the optocoupler and gate voltage is 12V. Other options used in board designs are MOSFET drivers, but these may or may not be isolated gate drivers.

7. Fuses. Since 3D printers can draw high currents for the heated bed, it can be a fire hazard if too much current is being drawn. Boards have components designed for a maximum current rating; above that, components may melt and burn. Fuses are therefore absolutely necessary to ensure that boards do not draw more current than what they are designed for.

Nowadays, when I see a new board on the market, I always look at the following (external appearance, and schematic if available):
- Does it have a separate connector for bed power?
- Does it have fuses?
- What is the MOSFET used for the heated bed?
- Does it have an optocoupler to isolate the bed supply from the supply used for the rest of the board?
- Does it have sufficient "heat sink" area under the bed MOSFET?
- What type of connectors does it use from/to bed supply, and from/to heated bed?

Hopefully, this helps people when they are selecting/design a 3D printer control board. And help prevent unnecessary fires.

Wednesday, December 25, 2019

Is Huawei more dangerous than Facebook and Google?

In a previous post, I wrote about the Huawei ban.

Here is a recent commentary about Huawei.
Commentary: Is Huawei dangerous because it’s Chinese? What about Facebook?

An excerpt:
The fear is that Huawei could gain access to a huge volume of data about us, which then could be used in a way that is detrimental to our interests, including by adversely influencing national politics.
But these threats already exist, because Facebook (which also owns Instagram and WhatsApp) and Google (which owns YouTube) have an astonishingly comprehensive range of data about their users – their location, contacts, messages, photos, downloads, searches, preferences, purchases, and much else.

I think we should read the article, and ask ourselves, "Are we biased against Huawei simply because it is Chinese? What are the facts backing those conclusions about the risk that Huawei pose? Are our conclusions based on our impressions and feelings, or are they based on facts that we know?"

It is an issue I have touched on before, about basing our decisions on facts and not feelings. And is our poor impression of China stemming from a "brainwashing" legacy from the Cold War that tells us that communism is bad? Are we looking at labels instead of facts?

Are we the mindless critters being told by Big Brother what to think? Or can we look beyond the labels and emotions to discern the truth from the facts?

Monday, December 23, 2019

"約束 (Yakusoku)": A fitting song for "My Tomorrow, Your Yesterday"

I was watching "My Tomorrow, Your Yesterday".


The movie is about two timelines, crossing each other every five years, but running in opposite directions.

And then I chanced upon this song, 約束 (Yakusoku) by リリィ、さよなら。(Lily Sayonara).

I thought it is a song that would really fit the story of "My Tomorrow, Your Yesterday". Especially the part about meeting and parting in each other's lives.

The lyrics:
「でも、もし生まれ変わったらその時は探すからね。」
そんな悲しいこと言わないで ‘来世で’ なんて望まないよ

イジワルなその笑顔も 大事なとこで噛むクセも
いつまでもいつまでも変わらないまま
遠くに行ってしまうんだね
大切に想える人見つかるといいね

生命線 その途中で出逢えたことさよならをしたこと
正しいとか間違いだとかそうじゃなくて君にありがとう

でも、もしまた出逢えるなら もし次があるのなら
今度はもう失くさないように 嘘もつかないから

子供みたいにニヤけるとこも 憂いを含んだ横顔も
いつまでもいつまでも変わらないまま
ただ君のその気持ちが離れていってしまった
僕はただ立ち尽くしていた

生命線 その途中でまたどこかで偶然出逢ったら
胸を張ってあの日のように 上手く笑って声をかけるね

その時は君は何て言うのかな…

生命線 その途中で迷ってしまうような日が来ても
振り返ればそこに君がいて 笑っていられる気がしたよ

生命線 その途中で出逢えたことさよならをしたこと
笑った日も傷つけ合った日々も伝えたい君にありがとう
伝えたい君にありがとう

でも、もし生まれ変わったらその時は探すからね
あの頃と同じように上手く笑ってほしい
(Source)

Saturday, December 21, 2019

Has the Skywalker risen?


I watched Star Wars: The Rise of Skywalker last night. As the last movie of the sequel trilogy, it brings a conclusion to the story of the main characters in the Skywalker saga.

Was it a great movie? Yes. Great visual effects, impactful scenes, everything that makes it worthy of the Disney name. And like a Disney movie, a (somewhat) happy ending.

The rest of this post will contain spoilers, so please take note.

At the end of Episode VI, Emperor Palpatine was defeated and gone, but the rest of the galaxy was still fighting against the (now leaderless) Galactic Empire. It was a happy ending in that the Rebels had won the battle. But there was still the war. But with Episode IX... the evil forces were more or less wiped out by the end of the movie.

Which brings me to ask: where is the balance?

I strongly believe that the Star Wars story is about balance. Anakin Skywalker is supposed to bring balance to the Force. And balance means that the Light side and the Dark side both exist. When the Light was strong, Anakin helped the Dark side to regain balance (but it tipped too much to the Dark as a consequence). Still, in Episode VI, Anakin brought balance back to the Force by preventing the annihilation of the Rebels by the Emperor when he fought against the Emperor. But he did not wipe out the Dark side.

With Episode IX, it would seem the entire Dark side had been wiped out when the Emperor was defeated. And if the Dark side is gone, there is no balance; it is just the Light. Where is that theme of balance? That eternal struggle between Light and Dark?

I do appreciate Rey calling herself a Skywalker at the end of the movie. Her story is one of learning to accept herself for who she is, but also about having the strength to choose to be who she wants to be. It is somewhat similar to what I wrote previously about my thoughts of what being a Skywalker means. But I also wrote about Skywalker being people who bring balance to the Force. In this sense, it is different since Rey has effectively destroyed the balance instead of restoring it.

To me, instead of bringing a proper conclusion, the story of Episode IX leaves a lot hanging.

Are the Skywalkers really the neutral party that brings balance to the Force? Maybe Rey's lightsaber, with a yellowish color, hints so. Being a more neutral color between the blue/green style of the Light, and the red theme of the Dark. But if so, the Dark side must have a way of surviving that total wipeout at the end of the movie. How?

How, in the first place, did Emperor Palpatine survive Episode VI? Did his hatred keep him alive even after sustaining grievous injuries from that fall into the reactor?

Why does Rey and Kylo Ren aka Ben Solo share that bond between them? Was this Force bond created through the same struggle that they face? That struggle between who they were born as, and who they aspire to be?

Is the film trying to say that Rey is the embodiment of balance, because she fuses nature (her Dark bloodline) and nurture (her Light training) into one single entity? If so, the sequel films should have done more to portray that struggle between bloodline and training. (Note: Yes, I think we can all say that Episode VIII was so far off that it probably killed every good idea, and J.J. Abrams did his best to bring things back to somewhat resemble a Star Wars story with Episode IX, the best given the train wreck from VIII.)

Anyway, like other films in the sequel trilogy, Episode IX has many scenes that were reenactments of past films in the series. I am not a fan of such reenactment. Yes, I agree that copying is a good form of compliment, but I think it is lazy. It would have been much better if the film makers used the Star Wars stories of the past and the universe it created to spin their own stories, their own scenes.

Maybe George Lucas should come out and talk about his ideas for the sequel trilogy. Star Wars: The Alternate Sequel Trilogy or something like that. Something less tinted by the Disney mass-market, happy-ending theme. Something that is an engaging story, and yet at the same time explores other human themes like Frank Herbert's Dune series.

Thursday, December 19, 2019

Using common LCD controller on MRR ESPE

The LCD connector on the MRR ESPE, which is an ESP32-based 3D printer board, is designed for the Creality CR-10 stock display, but that did not stop me from trying to get it to work with the more common RepRapDiscount Full Graphics Smart Controller (also called LCD12864). An adapter is used to break out the LCD connector pins to the EXP1 and EXP2 format.

Configuration.h needs to be changed:
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
#define ST7920_DELAY_1 DELAY_NS(500)
#define ST7920_DELAY_2 DELAY_NS(500)
#define ST7920_DELAY_3 DELAY_NS(500)
(I needed the delays to prevent garbled display, but please try without the delays, and only add them if the display is garbled.)

To use the SD card slot on the LCD controller, additional jumper wires are needed to connect the pins on the adapter to the respective pins on the MRR ESPE. The SD_EN jumper also needs to be removed.

Warning/Note: Before using the adapter, CHECK your LCD controller. The problem with Chinese clones is that some of the adapters have the EXP1 and EXP2 connected in reverse. The easiest way to check is to make sure your printer is not powered. Then, connect the cables from the MRR ESPE to the adapter, and from the adapter to the LCD controller. Next, using a multimeter, check for connectivity between the SD card slot on the LCD adapter (which is connected to GND) and the microSD card slot on the MRR ESPE (which is also connected to GND). If there is connectivity, good! It means that everything should work when you power up the system. If there is no connectivity, chances are the LCD controller has the EXP1/EXP2 connectors in reverse.

MRR ESPA and MRR ESPE available here.
Facebook page
Facebook group
GitHub repo

Wednesday, December 18, 2019

Rant: SAO War of Underworld Ep. 10

Rant warning: This is a rant.


LiSA, the singer who sings the ending theme song "unlasting" for the anime Sword Art Online Alicization: War of Underworld, just appeared on TV and sang that same song. Which prompted me to write this.

The latest episode, Episode 10, aired last Saturday. The War of Underworld series started out... well... much less like a harem anime compared to past SAO seasons. But with Ep.10, the harem thingy is back. Sigh. Sigh!!! Argh!!

Synthesis Knight Alice was a cool figure, committed to her mission of protecting the human world. But this episode turned her into a jealous, spiteful young girl when Asuna appeared. Then, to make the whole episode a disaster, there was a scene where all (okay, not all... there are more to come) these "Kirito fans/lovers" turned up and all agreed to trade stories with each other about their Kirito.

OMG. 🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦

I can understand people falling for Kirito. Nothing wrong with having crushes. I can understand Kirito having only eyes for Asuna. What I cannot understand is this "let's share" thingy. Like sharing a cake. There is no way this will ever happen in the real world. It is truly a teenager's fantasy in a dream world of the writer's own imagination totally removed from all reality.

Okay, rant complete.

Tuesday, December 17, 2019

First manual mesh bed leveling in months

It has been a while, but I did a manual mesh bed level today because I had some issues with prints lately. With the MRR ESPE, which supports a LCD controller, doing manual mesh bed leveling was quite easy. But babystepping does not work on the I2S stream now, so that is a bit of a bummer. (Picture above is an Ender-3 with a quick "first layer test" after completing the manual mesh bed leveling.)

The MRR ESPA, which does not support LCD controller, can do manual mesh bed leveling too over the webUI. Just a bit less reactive since a gcode needs to be sent for each step of correction. Still, with macros on the webUI, this can be less of a hassle than actually keying in gcode commands over the serial terminal in the webUI.

I took time to do manual mesh bed leveling for the modified FLSun Cube too.
Same gcode file for the "first layer test" on the bigger bed of the modified FLSun Cube, but I think it is enough to satisfy me that the manual mesh bed leveling was done properly.

Thursday, December 12, 2019

I2C OLED display on MRR ESPA running Marlin fork


I did a quick test today to see if Marlin's support for an I2C OLED display can work out of the box with the MRR ESPA.

So I hooked up a 0.96" I2C OLED display (VCC -> 3.3V; GND, SDA, SCL to respective pins on MRR ESPA), then edited Configuration.h to enable
#define U8GLIB_SSD1306

Hit compile, uploaded the firmware to the board, and yes! It works! This provides a simple status screen for the MRR ESPA; a web browser is still needed to access the web interface for full control. But at least you can see the position and temperature settings.

Some background. I knew that ESP3D supported OLED displays via I2C, and also knew that the ESP32 did not have enough pins to support a LCD controller like the RepRap full graphics smart controller. So the MRR ESPA was designed to have the I2C pins (SDA and SCL) unused so that they can eventually be used to connect some kind of controller over I2C. The next step is to see if we can find some form of I2C keypad that can be used with Marlin. Or an ADC keypad like the one used on older Anet printers. But the ADC keypad will need to be connected to an ADC pin on the ESP32, and the remaining breakout pin (IO0) is not a suitable candidate since its ADC is being used by WiFi.

MRR ESPA and MRR ESPE available here.
Facebook page
Facebook group
GitHub repo

Monday, December 02, 2019

The history of MRR ESPA: Ready for launch

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. This is the final post in a series of posts about how the board was developed.

The darkness gives way to bright skies...

Having solved the heat dissipation issues, I came up with v1.1 as the production version. Which meant I removed most of the header pins since they were already connected to something and cannot be used for anything else. The board was also made slightly smaller, because by now, I had already spun off the MRR ESPE (aka I2S version), knew where to place the 74HC595s for the I2S version, and could afford to try and save board space.


And then v1.1 worked so well for me in my tests, I decided to try and improve it.

So I added the TMC2130 SPI support via jumper settings back to the design, which required quite a bit of routing the traces. And other jumper features like disabling VUSB, and a way to drive the bed MOSFET at a higher gate voltage. Thus was born v1.2.


This was supposed to be the version to be launched. It worked really great. But I still had to tweak it with small improvements (like a debouncing capacitor for the reset button), and eventually ended up with v1.3 as the "final" version to be launched.


And this concludes the series on how the MRR ESPA was born into its current shape. There may still be some really minor tweaks to the MRR ESPA in the future, but I don't expect anything major since the pins on the ESP32, without any expansion, are really limited.

(A series of discussions covering v1.1 to v1.3 can be found here.)

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