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.

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.

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!

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.

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.

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

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.

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?

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.

Happy New Year 2020!

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

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

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.

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?

"約束 (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)

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.