Monday, March 09, 2020

Using git from within VS Code


Okay, I know I am behind the times. But I finally got around to exploring what an IDE can actually do beyond just being a fancy text editor. After all, the "I" in IDE is for integrated, so an IDE actually has a lot of integrated functions to help make life easier for programmers.

I have been using GitHub for a while, and had to try and figure out git during this time. First, most of the stuff was via the command line, which can be quite tedious. Recently, I discovered GitHub Desktop, which helps to make life easier since it is a GUI for all those command line stuff. But now, I realized that VS Code actually has all these functions built into it in the first place. I don't really need GitHub Desktop. Or git-cola.

The source control panel in VS Code really makes life so much easier for me, since most of my actions would be staging, committing, and pushing on my own repositories.

As for compiling Marlin firmware, it makes life easier for me too, since I can easily discard previous changes to the configuration files. Then pull the latest version off GitHub. And with the Meld Diff extension, I can then select to compare the new configuration files with the set that I keep in another directory, and the extension will then call up Meld for me to merge the old and new configuration files.

For pull requests to Marlin, VS Code's source control also allows me to create a new feature branch, add my changes, then push that feature branch to my Marlin fork. I can then go online to send that PR. (The GitHub Pull Requests extension even allows PRs to be submitted from within VS Code.)

Going forward, I will try to use VS Code as much as I can in my new workflow.

Saturday, March 07, 2020

Workflow to compile Marlin on a SBC

I am going to try a new thing. I have a few single board computers on hand, and I am going to use them to compile Marlin. This is a note to self in case I forget the workflow.

So, the workflow is likely to be:
git clone https://github.com/MarlinFirmware/Marlin.git
to get the Marlin repository.

Then,
cd Marlin
git checkout bugfix-2.0.x
to get to the bugfix-2.0.x branch.

Edits to Configuration.h and Configuration_adv.h will be made as necessary, the compiled using PlatformIO on VS Code.

To pull the latest changes:
git checkout -- .
to get rid of all previous changes.

git pull
to get the latest code.
Then make changes.

Monday, March 02, 2020

Some thoughts about the political and economic impact of COVID-19 on China

Xi Jinping's coronavirus crucible

It is true that once supply chains have adjusted away from an existing supplier, they rarely shift back. But the issue is not a simple one. For one, production facilities are capital investments that are expected to run for a certain period of time in order to pay off that initial investment. Shifting away from an existing facility means writing off a previous investment, and even if it is just a portion of that initial investment, still represents an implicit loss. This is just not a move most companies, focused on making profits, will undertake easily.

Couple that with the investment that needs to be made in other countries to create production facilities there, and you will see that this is not a light decision for many. Companies need to fund such an investment, and it is no small sum. Not many companies have that kind of reserves to draw on, nor that kind of credibility for them to borrow from banks. Especially if they are already trying to pay back a previous loan from an existing investment in China.

And then there is the labor force issue. To shift production to another country, that country needs to have sufficient surplus labor for such an increase in production. You are either looking at a country with high unemployment, which may imply poor infrastructure and other conditions not conducive to investments, or you will need to throw in further capital investments to improve workforce productivity. This, again, boils down to more money.

There is also the time factor. It takes time to build a factory, it takes time to build the machinery for that factory, it takes time to recruit people to work in that factory, it takes time to apply for the required permits. You are not looking at something that can be done in a month or two. Unless companies already have plans in the works, trying to start this endeavor anew is going to take time. Lots of time. Time which companies may not be willing to spend, since they have the choice of allocating those same resources to catch up on production after their Chinese factories resume work.

So while there are people who speculate that manufacturing will leave China, it may not be on a scale as large as they expect, and it may even be something that has already been part of the plan before the coronavirus hit. As for the long-term impact on the CCP from this outflow? Well, given that the CCP has been trying to shift its industry focus away from a manufacturing-bias toward production higher up the technology and value chain, speculations about the impact to Xi's regime may be exaggerated. Only time will tell.

But remember, it is not easy to find a replacement for an economy with a workforce of several hundred million people and the infrastructure to support being a global manufacturing hub.

As for the voices of dissent? In a population of more than a billion people, there will be people who feel differently. We need to ask ourselves, are the voices of dissent that we hear the voices of the majority? Or are these people the vocal minority? Do they really represent a general lack of support for Xi and the CCP? Or are we just hearing them, even though they are but a minority, because their voices fit our existing mindsets and are the voices we hope to hear, want to hear?

Are these voices like those of the gun supporters in the U.S.? Where the majority actually wants gun control, but that small vocal minority has hijacked the entire conversation such that the majority gets ignored? Are we listening to the voices of a small minority whose dissent we want to hear, at the expense of ignoring the vast majority who actually have nothing against Xi and the CCP? Are we ignoring facts for feelings?

If we backtrack a bit to 2019, the Hong Kong protests, I think the early protests really had the CCP worried. Because the majority of the Hong Kong people really were against CCP interference in Hong Kong's legal system. But when a small minority hijacked the protests for their own political objective, and turned the protests into increasingly violent riots, and made demands beyond the initial extradition law? Well, people at first continued to stand together since that was the best way to get things done. But eventually, the majority drifted away, since those "extra" political terms were not something they felt strongly about.

Today, if we look at the facts, I don't think Xi and the CCP are as worried about the political impact of the coronavirus as Western writers speculate them to be. Compared to the U.S. and Japan, China has shown that it is willing to move quickly to contain a threat. The epicenter of the disease is in China, but China has shown that it is able to act swiftly and decisively. Contrast that with the slow actions of Japan, where Abe is only recently starting to take firmer actions to contain the spread. Yet it seems that the disease has already spread further in Japan than Abe wants to admit. And the U.S. is showing that same trend, with more and more cases of community infection, but also more and more denial from the Trump administration.

Companies are not stupid. Like the majority of the Hong Kong people, who know when their cause is being hijacked by a minority for other political aims, companies can see the responses of countries, the results, and they will make their production decisions based on what they see. After all, it is through decisions based on facts that we can operate a tighter and faster OODA loop than our competitors. Those who base decisions on feelings end up in an OODA loop that is increasingly removed from reality, until they become obsolete.

Wow. This post has become a very long rambling of thoughts. Guess I am going to stop here before I really go off tangent.

Mini 3D printer for demonstrations

I have been searching for a small 3D printer as a platform for showcasing the MRR ESPx boards at local maker fairs and such. I was going to build one based on an open source design when I find something that I like.

Then, I happened upon this on Amazon.


It seems to be small enough to transport around, and since the control box is a separate part of the build, I can easily just house the MRR ESPx board in my own control box. The only thing is that it lacks a heated bed, but I guess I can live with using stick glue. If need be, I can always slap a small silicon heating pad under the bed, but I will then need to get a better power supply.

EasyThreed X1
http://www.easythreed.com/
(The one I found on Amazon is a local reseller.)

I guess the only way to find out if this is going to work is to actually get one and try. Wish me luck!

Karez water system (video)

Many many years ago (more than 20, actually), I went on a trip along the Silk Road. One of the places visited was Turpan, where we saw the karez water system which supplies water to this city in the middle of a desert.

So when I saw this video, I just thought I would share it for more people to learn about this interesting water system, an ingenious way of dealing with the issue of water in a desert.

Friday, February 28, 2020

Practical 3D printing: Outer case for RPi "armor case"

There are tons of Raspberry Pi cases out there, but I happen to have this "armor case" for my Raspberry Pi 3B+ and 4B. The "armor" case is basically two pieces of heat sink for the entire top and bottom of the RPi. Works great for passive cooling, and with 2 x 25mm fans, has an active cooling option too. But they look... dull.

And the tons of RPi cases out there can't fit my RPi enclosed already in an "armor case". So it was time for practical 3D printing.

Open FreeCAD, and design the bigger "case" that will wrap around the "armor case". Slice it, and tada!

I actually messed up the bottom a bit. The RPi is supposed to go with an external SSD mounted below it, so I had to redo the bottom a bit. But I finally got it right.

Time to get that mount done for the external SSD.

Nothing too fancy, just a simple case to allow me to mount the RPi on top of the SSD with M3 bolts.


The case works for RPi 3B and 3B+ in "armor cases" too.

Now to find other practical stuff to print.

Update (March 13, 2020):
The above design "cooped up" the armor case, which sought of made it less effective in cooling the RPi4. I updated the design to expose more of the armor case.

As the picture shows, it works for the armor case of the RPi3 too.

Thursday, February 27, 2020

The Chinese have discovered Marlin runs on ESP32

在ESP32开发板上安装Marlin
(Installing Marlin on ESP32 development board)

This is a step-by-step guide on how to compile Marlin and install it on a ESP32 development board, including enabling and loading the ESP3D webUI. The author even mentioned the MRR ESPA (which he used to figure out the pin assignment). It seems he could not figure out what the pins numbered above 100 were for in other boards, but it will be a matter of time before he figures it is for the I2S expansion.

I guess it is a matter of time before existing designs get cloned and we see a new wave of ESP32-based 3D printer control boards. I just hope they at least credit the designs they "referenced".

Saturday, February 22, 2020

Testing Trinamic stepper drivers on MRR ESPA and MRR ESPE

Following the testing of slave addresses on TMC2209, I have done some further testing on Trinamic drivers on the MRR ESPA and MRR ESPE boards.


The following are the test setups:

1. MRR ESPA with 4 x TMC2209 in UART mode
Pins 21 and 22 were used for hardware Serial1, and slave addresses 0 to 3 were used for X, Y, Z, and E0 respectively. I ran into this issue while compiling (workaround also included in the issue), hopefully it gets resolved soon. With this setup, I also managed to test sensorless homing, and it works!

2. MRR ESPA with 3 x TMC2130 in SPI mode
Pins 21, 22, and 0 were used for CS pins of X, Y, and E0 respectively. These are the only 3 unused pins on MRR ESPA, so a fourth driver could not be tested, but this should not be an issue on the MRR ESPE which has five unused pins.

3. MRR ESPE with 3 x TMC2209 and 1 x TMC2208 in UART mode
Pins 21 and 22 were used for hardware Serial1, which supported the X, Y, and Z axes using TMC2209 with slave addresses 0 to 2. Pins 2 and 4 were used for hardware Serial2, which supported E0 running TMC2208 (no slave address). This mixing of TMC2209 and TMC2208 drivers work! Technically, this means 4 x TMC2209 can be on Serial1, while the fifth stepper driver can be 1 x TMC2208 or TMC2209 on Serial2. BTW, this is the setup shown in the photo (almost; the photo does not show the TMC2208 hooked up properly to Serial2).

This more or less concludes the testing of Trinamic stepper driver support on the MRR ESPA and MRR ESPE boards. My current printers are running a mix of TMC2209/A4988 on one, and TMC2130/A4988 on another printer. With this test completed, I will likely be using TMC2209s exclusively for one of them, and TMC2130s exclusively on the other.

A pull request has been submitted to Marlin to make it easier for users to configure the pins for hardware serial. Hopefully it gets merged soon.

Get the boards here.

MRR ESPA and MRR ESPE related social media:
Facebook page
Facebook group for users

Friday, February 21, 2020

Flash firmware to MRR ESPA and MRR ESPE correctly

The blue screen of death on my LCD controllers made clear an issue with the ESP32 boards (MRR ESPA and MRR ESPE). The issue is the state of pins when the ESP32 microcontroller is in "download" mode (GPIO0 pulled to GND when booting up; ESP32 datasheet states the default states of pins on reset but not during "download" mode). While waiting to flash new firmware in this "download" mode, output pins could be in the HIGH state. Which may be potentially disastrous.

Why?

For one thing, it means current will be flowing to the heating elements WITHOUT control. For the brief moment of one to two seconds when booting up, this is not an issue. But if GPIO0 is pulled to GND for an extended period, this continuous and uncontrolled heating for the heated bed and/or hotend can potentially result in fire.

Another possible problem is when the fan connector is connected to a laser engraver. This could potential turn on the laser, and burn whatever the laser is pointed at.

Therefore, please NEVER try to flash firmware via the USB port when VIN is connected.

The right way to flash firmware?
Method 1: Disconnect wires from the board. Power the board via VUSB via the jumper. Connect the board to the computer via USB and flash the firmware.
Method 2: Use the ESP3D webUI to update the firmware. This is the safer and easier option, but can only be possible if the board has already been flashed beforehand to incorporate ESP3D support.

(Critical output pins on the MRR ESPA and MRR ESPE should have resistors to pull them high or low depending on what their default state should be, so this should not be an issue during normal bootup.)

Wednesday, February 19, 2020

MRR ESPE v0.5 pre-launch version sold out!

A while back, I made the pre-launch version of the MRR ESPE v0.5 available for those who want to give it a try. As of today (February 19, 2020), the pre-launch version of MRR ESPE v0.5 has been sold out.

If enough people are interested, I will attempt another Kickstarter to try and fund it. Register your interest in the comments here, or a comment in this Facebook page post.

Meanwhile, the MRR ESPA v1.3 pre-launch version is still available here.

 
Update 20 October 2020: MRR ESPE v0.5r1 (with the AUX1 pins fixed) is now available in limited quantity. You can get it here.

Improving the FLSun Cube

It has been a while since I tried to do a proper print with my modified FLSun Cube. After converting it to a coreXY setup, I have been using it more for testing purposes (to see how the MRR ESPA and MRR ESPE would work with 12V and coreXY systems), and most of the prints are test cubes and first layer tests.

The modified Cube was also not very well modified. Totally my fault, arising from trying to kit bash many many different parts from various builds to get something that I want. Couple that with a somehow warped bed (even with the Ultrabase glass bed, my mesh readings can various by 0.15mm or more between each probe point), and it is no surprise that I try not to use it for anything meaningful.

Still, I added stiffer springs to the heated bed recently, did a manual mesh bed leveling again, and needed to see if it works. So I did a more proper print this time. A holder for a portable SSD that I will be using with a Raspberry Pi 4.


The print completed without failure, but quality was poor. I think there is some friction in my bearings/rods, and the way my spool holder is mounted seems to result in poor filament feeding. I will be relocating the spool holder, but there is nothing much I can do about the bearings/rods except for a total teardown and rebuild. Which is why I am still searching for a build that will allow me to use linear rails (I have 3 x 400mm MGN12H rails), microswitches for endstops (instead of optical switches), and a Titan Aero direct drive extruder.

Anyway, the printer is running on a MRR ESPE with TMC2130s on X and Y. The only noise it makes are from the friction between bearing/rod, and when the filament spool is pulling on the XY gantry. And the 5015 fan when it is first starting up; but that noise drops significantly once the fan is running smoothly.

The 3030 extrusions for my pending HEVO build is still lying around gathering dust...

Saturday, February 08, 2020

Blue screen of death

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.

This is how the LCD controller looks like.



Wednesday, February 05, 2020

The rule of law, East vs West

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.

My thoughts about the economic impact of the coronavirus

Clock is ticking for companies that depend on China imports

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. 

Monday, February 03, 2020

Troubleshooting layer shifts during 3D prints

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!