[BUG] TFT_LVGL_UI (MKS_UI): Y axis motion loss / offset, does not occur with TFT_COLOR_UI

[phcay]

Did you test the latest bugfix-2.0.x code?

No, but I will test it now!

Bug Description

MKS_UI: Y axis movement loss / offset, does not occur with Marlin color UI

Bug Timeline

First use of official Marlin on this printer. Use of the TwoTrees (custom MKS) and MKS variants beforehand.

Expected behavior

No response

Actual behavior

When using MKS_UI there are Y axis movement losses / offsets at random Z heights, does not occur with Marlin color UI. The offsets generated can reach the entire width of the printed layer. Note that my motherboard is an MKS Robin nano 1.2 and does not have uart / spi communication with the drivers, which are therefore in standalone mode, and Marlin cannot affect their current setting. By significantly increasing acceleration and printing speeds, the problem seems to occur less, or even disappear, but it would take a lot more testing to confirm this. On this printer, a TwoTrees Bluers, I used MKS_UI with the fork of Marlin 2.0 from MKS beforehand with a fairly similar setting without this anomaly appearing.

Steps to Reproduce

No response

Version of Marlin Firmware

2.0.9.2 (+commits 04/10/2021)

Printer model

TwoTrees Bluer V1+ (V2 in Marlin)

Electronics

Stock MKS Robin nano 1.2 x+y=tmc2208, z+e=tmc2209

Add-ons

BLTOUCH, MKS WiFi

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

No response

Additional information & file uploads

Slicer is SuperSlicer.

I am using "#define MKS_UI" to switch between Marlin_color_ui and MKS_UI, with conditions on SERIAL_PORT_2, Marlin LCD menus, FILAMENT_RUNOUT_SENSOR, ADVANCED_PAUSE_FEATURE, TFT_LVGL_UI and TFT_COLOR_UI.

Configuration.h.txt Configuration_adv.h.txt

[phcay]

I tested yesterday with the bugfix-2.0.x of 10/19/2021 and the result is the same. I don't know if it is strictly related to MKS_UI or to other related things like MKS_WiFi. I saw that MKS released Robin nano firmware based on Marlin 2.0.9.2. When I have a moment, I'll test him to see if he reacts the same.

[phcay]

For information, I also tested on another printer, an ender3 with an MKS Robin Nano 2.0 card, and it's the same. With TFT_COLOR_UI, no problem. With TFT_LVGL_UI, random shift on the Y axis.

[Rockman18]

I experience the exact same bug since a while on my Two Trees Bluer modified with :

• MKS Robin nano v2
• TMC2209
• BLTouch
• MKS_WiFi

• MKS PWC

  I'm on the latest bugfix-2.0.x with TFT_LVGL_UI. On every print, I have Y axis shifts, more or less important 1-2mm or sometime very huge. Tonight, during a calibration cube one Y move was fully inverted and the extrusion find itself in the void.

I'll try TFT_COLOR_UI

Edit : TFT_COLOR_UI solves this issue.... Thanks for the hint. Hope MKS_UI will be fixed soon !

[phcay]

Yes, in addition to my Two Trees bluer with the MKS Robin Nano v1.2, I also have a Nano 2.0 on an Ender3, without WiFi module, with TMC2209 (in uart, unlike v1.2). Both printers present the same bug when using TFT_LVGL_UI, including on the MKS fork of Marlin 2.0.9.2 for Robin Nano.

Rockman18, can you provide your configuration.h and configuration_adv.h so that I can compare with mine.

I tried to analyze the code, but so far I haven't found any convincing leads. What is strange is that it only affects the Y axis.

[WesleyvH]

Confirmed, had the same problem. Layer shifts on Y axis after flashing this version of Marlin. Switched to TFT_COLOR_UI from TFT_LVGL_UI and it fixed the layer shifts.

Using custom built printer with MKS Robin Nano v1.2. XYZ TMC2208 E0 A4988 No WiFi Module

[Rockman18]

Yes, in addition to my Two Trees bluer with the MKS Robin Nano v1.2, I also have a Nano 2.0 on an Ender3, without WiFi module, with TMC2209 (in uart, unlike v1.2). Both printers present the same bug when using TFT_LVGL_UI, including on the MKS fork of Marlin 2.0.9.2 for Robin Nano.

Rockman18, can you provide your configuration.h and configuration_adv.h so that I can compare with mine.

I tried to analyze the code, but so far I haven't found any convincing leads. What is strange is that it only affects the Y axis.

@phcay : Here are my configuration files https://github.com/Rockman18/Marlin/commit/36615bd75bbbe0967276b148674cf2a151482ba1

[mmaaddzz]

I have the same issue with 2.0.9.2. Objects are shifted in Y direction starting from random height. Board is Robin Nano v1.2 with TMC2209 drivers with serial connected to unused E1 pins. Without MKS_WIFI_MODULE. Config.zip .

[phcay]

I also opened a ticket on the MKS fork, which is also affected by the same issue since they reconciled with version 2.0.9.2, and other users reported the same issue. This seems to only affect the Nano V1.2 and V2, but not the V3 (I have one in stock, when I have a little more time I would do a swap with the V2 to confirm or not that). I suspect that there is a conflict of use of the PINs used for the Y axes, with an alternative function of these PINs (TIMER4, JTAG, FSMC, I2C, SDIO ...), which would also explain that this does not not happen on V3.

define Y_ENABLE_PIN PE1

define Y_STEP_PIN PE0

define Y_DIR_PIN PB9

PinName Type I / O-Level Main-function- (after reset) Alt-funct-Default Alt-funct-Remap PB9 I / O FT PB9 TIM4_CH4 (9) / SDIO_D5 I2C1_SDA CAN_TX PE0 I / O FT PE0 TIM4_ETR / FSMC_NBL0 - PE1 I / O FT PE1 FSMC_NBL1 -

But I don't have enough knowledge to find or fix this yet.

[gsalvati]

Se problem here MKS Robin nano 1.2 TFT_LVGL_UI. Custom built based on BLUER configuration source.

[daniDevKr]

I have a similar problem with my MKS Robin Nano V 1.2 board. My marlin version: Marlin 2.0.9.2 The printed object have some shifted layers. configurations.zip model.zip

[dblatt87]

Maybe same problem here: Saphire Plus, Robin Nano 1.2, MKS UI, TMC2209... For the hole config see my fork https://github.com/dblatt87/Marlin-for-TT-Sapphire-Plus/ Huge layer shifts with Marlin 2.0.9.2 and also bugfix 2.0.9.3. I went back to 2.0.8, no problems there.

[Alex-TV]

I have this problem too. mks robin nano v 1.2, Marlin 2.0.9.3, LVGL UI (MKS UI)

[solawc]

When I switched back to Maple, it was almost normal, I saw someone saying it was normal in 2.0.8, apparently that was because in the same pio environment, marlin used maple, and now it is replaced by STM32 HAL , I think it's a big deal, of course this is my personal opinion and needs to be verified, and I'm doing

[solawc]

I also opened a ticket on the MKS fork, which is also affected by the same issue since they reconciled with version 2.0.9.2, and other users reported the same issue. This seems to only affect the Nano V1.2 and V2, but not the V3 (I have one in stock, when I have a little more time I would do a swap with the V2 to confirm or not that). I suspect that there is a conflict of use of the PINs used for the Y axes, with an alternative function of these PINs (TIMER4, JTAG, FSMC, I2C, SDIO ...), which would also explain that this does not not happen on V3.

define Y_ENABLE_PIN PE1 #define Y_STEP_PIN PE0 #define Y_DIR_PIN PB9

PinName Type I / O-Level Main-function- (after reset) Alt-funct-Default Alt-funct-Remap PB9 I / O FT PB9 TIM4_CH4 (9) / SDIO_D5 I2C1_SDA CAN_TX PE0 I / O FT PE0 TIM4_ETR / FSMC_NBL0 - PE1 I / O FT PE1 FSMC_NBL1 -

But I don't have enough knowledge to find or fix this yet.

I am very interested in the question you raised, but I am thinking, if it is caused by multiplexing, will it also appear in the TFT COLOR UI? But it seems that TFT_COLOR_UI does not have this problem

[dblatt87]

I also opened a ticket on the MKS fork, which is also affected by the same issue since they reconciled with version 2.0.9.2, and other users reported the same issue. This seems to only affect the Nano V1.2 and V2, but not the V3 (I have one in stock, when I have a little more time I would do a swap with the V2 to confirm or not that). I suspect that there is a conflict of use of the PINs used for the Y axes, with an alternative function of these PINs (TIMER4, JTAG, FSMC, I2C, SDIO ...), which would also explain that this does not not happen on V3.

define Y_ENABLE_PIN PE1

define Y_STEP_PIN PE0

define Y_DIR_PIN PB9

PinName Type I / O-Level Main-function- (after reset) Alt-funct-Default Alt-funct-Remap PB9 I / O FT PB9 TIM4_CH4 (9) / SDIO_D5 I2C1_SDA CAN_TX PE0 I / O FT PE0 TIM4_ETR / FSMC_NBL0 - PE1 I / O FT PE1 FSMC_NBL1 -

But I don't have enough knowledge to find or fix this yet.

Just searched in 2.0.9.2 where the Y-Axis pins (PE0, PE1, PB9) are used. I'm only a hobbyist but I find them only in the robin nano pin definitions (where they should be) and in some variants not related to stm32f1. I don't realy know which variants are geting included, but in my opinion it's not a pin definition conflict.

[LLHCrack]

I also encountered exactly the same problem as you. With the same equipment, I lost steps for the y-axis, but I used marlin2 provided by MKS 0.9.2 becomes the number of steps lost in the x-axis

[pash7ka]

I can confirm the problem on FB Ghost4s with TMC2209 UART drivers and MKS_UI (I'm using configuration by @Sergey1560 with minor changes for UART drivers connection). Also i can confirm it's somehow related to using HAL instead of maple, because after switching _defaultenvs from mks_robin_nano35 to mks_robin_nano35_maple i don't have this problem any more.

[thinkyhead]

Would you be able to test some bugfix-2.0.x commits to narrow this down?

The strategy is to find a commit from some point in the "distant" past where the feature works. Then, test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact day where it broke.

If you started from a point 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it.

[pash7ka]

Yeah, i see the idea, but for me it looks like the point where it was broken - is the point where mks_robin_nano35_maple where switched to mks_robin_nano35. In the configuration I'm using, COLOR_UI also uses mks_robin_nano35_maple. So probably the first thing we need to check - if we have this problem with COLOR_UI and mks_robin_nano35 env. I'll check that.

[Rockman18]

Yes this issue appeared when switching from mks_robin_nano35_maple to mks_robin_nano35. 5 month ago, I switched to COLOR_UI with mks_robin_nano35 and I have no issue anymore. The issue is only with TFT_LVGL_UI, not with COLOR_UI.

[ikkez]

I just found something similar, but I don't know if it's related. Can you try to just touch the "Options" Menu-Button on the overview screen while printing and don't leave that options screen and compare the print results. I know it sounds stupid, but there's something in TFT_LVGL_UI on the print screen that causes micro freezes in movement, see my issue here https://github.com/makerbase-mks/MKS-Robin-Nano-V3.X/issues/100

[dblatt87]

Actualy my printer runs fine on Marlin 2.0.8 and same config like my shift affected build 2.0.9.3. (both builds with mks_robin_nano35 defined and TFT_LVGL_UI). And I also recognised these micro freezes.

[PatricLeal]

I've been having the same problem of some random deviations on skr 1.4 turbo + tmc2209 uart + btt tft24 v1.1(Marlon 2.0.9.3), I found that in some of the cases the y wall on one side gets thinner or there is a layer displacement in the y. At first I thought it was a slicing error but I checked an occurrence in cura and prusaslicer remains when checked gcode is correct, but when I run gcode on the same machine using klipper the error does not occur.

[GenoMXXX]

Can you fix this in new version? Thanks! I have this problem on my mks robin nano v 1.2, Marlin 2.0.9.3, LVGL UI (MKS UI)

[brainstorm1313]

Has anyone tried to install the new version 2.1? Has the problem gone away?

[AlexejLach]

mks robin nano v2 tried marlin 2.1 the problem remained! when will you fix it?

[mjbogusz]

I've encountered the same problem on Sapphire Pro (CoreXY layout), MKS Robin Nano 1.2, TMC2208_STANDALONE on X and Y axes. Same behavior on both 2.1.x and bugfix-2.1.x - random motion anomalies on the Y motor (X-Y axis) ranging from few mm to over 20mm.

I think that the LVGL option in the reference Configuration.h should be guarded by a #warning notifying users about this issue - I've spent 3 days (!) fiddling with belts, motor mounts, driver reference voltages, Marlin configs and slicer parameters trying to find the cause of the missed steps only to stumble upon the source of the problem by chance while looking for something unrelated.

For reference, the issue was also reported on MKS's fork as well (with no response from MKS as far as I can tell): https://github.com/makerbase-mks/Mks-Robin-Nano-Marlin2.0-Firmware/issues/293

[aaroncnc]

Oh my god an entire week down the drain chasing my tail till i found this issue. needed to reflash the printer to enable a laser cutter add on and have been suffering random Y shifts from that point. I have even tried slowing the machine down to a crawl and cranking the morotr current up and even adding a blower fan on the drivers. even switched to uart mode but still have shifting in the Y axis I switched it to TFT_COLOR_UI and have had no issues for the last 5 hours of prints.

Can someone please take a look at this defect. Or at the very least push a warning message when the board is set to the mks nano to not use the LVGL UI?

An entire week and tons of filament later. trying everything under the sun. took apart the y axis 3 times. switched drivers to external ones. added temp probes to the drives and motor. Current monitored them as well. Changed speeds settings down to a crawl. None of that time comes back.

[aaroncnc]

seems i have spoken to soon. Had to build marlin 2.0.8 to fix more lost y steps.

Something about rapid changing fan speeds is causing lost y steps even when running color ui. This makes it worse. Synchronous Laser Control with M106/M107 When it is enabled i seem to start losing steps alot faster in y. https://drive.google.com/file/d/1AiiPZZF9s5SFFNLTPLWnzFuYZGW-O3RA/view?usp=sharing

in the above image all those objects should be equal squares.

When running marlin 2.1.1 as a 3d printer running normal gcode using color ui i have not seen any lost steps. But when i load up laser cutter g code with lots of fan changes the lost steps came back. Code below https://drive.google.com/file/d/1c0wDMHzAKruOvq7uhAoH7qhr1LppZe9p/view?usp=sharing

Am currently doing more testing and will see if more lost steps show again.

[phcay]

very interesting what you saw with the interaction with the fan/laser. Are you using software or hardware fan pwm?

[aaroncnc]

im not sure. i am using the stock fan port but have a break out on the back of the mosfet to grab the signal line going to my laser driver. im not sure how to tell but its on pin PB1

[thinkyhead]

The best way to track down the cause of a bug is to use "Git Bisect." But, someone experiencing the bug has to do it so they can test to see whether the bug is present after each bisection. https://www.youtube.com/watch?v=D7JJnLFOn4A

[thinkyhead]

Am currently doing more testing and will see if more lost steps show again.

Try increasing the BLOCK_BUFFER_SIZE to 128 or 256 and see if it helps.

[phcay]

im not sure. i am using the stock fan port but have a break out on the back of the mosfet to grab the signal line going to my laser driver. im not sure how to tell but its on pin PB1

The activation of software PWM is done with "#define FAN_SOFT_PWM" in the "Configuration.h" file. The Nano v1.2 and v2 have hardware PWM for the fan, so we have a choice, but for the Nano V3 it doesn't, so we are forced to use software PWM on that.

Personally, I prefer the software for "fans". It uses MCU, but the frequency is much lower and therefore they are quieter and increase their range of use in the low percentage, whether for starting or maintaining, very useful when printing in ABS or similar, where when you need to cool, it must be very weak.

[aaroncnc]

so i am try to bisect but am having trouble getting reliable results. It fails only sometimes. in different places then other times it works fine.

Is there any g code generator or someone can whip up something that spams the crap out of fan speed and lots of Y moves? Thinking about using the good firmware and make a pen attachment so i can tell if it misses steps without having to print a ton or running the laser.

[dblatt87]

You can loop somthing simple like a circle or square including fan regulation as many as you wan't with M808. Sure it would be the best to this without extruder, laser or whatever your tool is, just simple movement code. Depending on your hard and firmware it may also be possible to detect a layer shift with a probe or endswitch. I never tried something like that, but could imagine some scenarios.

[aaroncnc]

if someone has a way to use the end stops to check that would be amazing. i can manually write some code for it to move around and change fan speed. my current plan was going to have it move around in open air above the bed for 1 min then come down with a pen and draw a circle every 1 min for about 20 min. A very quick visual check would show if any shift happened as the circles would not be stacked but offset. So if after 5 min i notice a circle is not stacked i know that branch of software is bad and can abort the test. But if there is a way to use the end stop that would be better

[dblatt87]

first of all, be sure the shift is towards the endstop if yu have only one like most printer have. In the Configuration_adv.h just #define ENDSTOPS_ALWAYS_ON_DEFAULT. You can easy check it with hiting them manually while moving after homeing.

[aaroncnc]

You lost me there. The shift is in any random direction on the y both towards and away.

[mjbogusz]

Bumping, as this issue won't go away on its own without a fix.

[AlexST-77]

The bug is still exists on latest bugfix with MKS Robin Nano 1.1 board. But one moment - I have tested with moving driver of Y axis from Y to E1 socket on the board (with changing a pinouts) and cannot reproduce the bug.

[makarenya]

It's some sort of dark magic, but I can confirm previous statement... Flying Bear Ghost 5. Moving driver to E1 socket and changing pinout solve the problem. But looking onto board layout... No difference between ways of tracks, connected X and Y drivers... Yes, Y_DIR_PIN located near Z_ENABLE pin... But how it can affects only in MKS UI... No, it must be a software problem. Maybe something when working with port E? PS: Why i can't flash board with mks_robin_nano_v1v2_maple? TFT Updating hangs on 100%, and, if I reboot it, only black screen shown.

[phcay]

I also opened a ticket on the MKS fork, which is also affected by the same issue since they reconciled with version 2.0.9.2, and other users reported the same issue. This seems to only affect the Nano V1.2 and V2, but not the V3 (I have one in stock, when I have a little more time I would do a swap with the V2 to confirm or not that). I suspect that there is a conflict of use of the PINs used for the Y axes, with an alternative function of these PINs (TIMER4, JTAG, FSMC, I2C, SDIO ...), which would also explain that this does not not happen on V3.

define Y_ENABLE_PIN PE1 #define Y_STEP_PIN PE0 #define Y_DIR_PIN PB9

PinName Type I / O-Level Main-function- (after reset) Alt-funct-Default Alt-funct-Remap PB9 I / O FT PB9 TIM4_CH4 (9) / SDIO_D5 I2C1_SDA CAN_TX PE0 I / O FT PE0 TIM4_ETR / FSMC_NBL0 - PE1 I / O FT PE1 FSMC_NBL1 -

But I don't have enough knowledge to find or fix this yet.

Yes, we come back to the track I mentioned. And given our various experiences on the subject, I am more and more convinced that something at the level of the DMAs or TIMERS triggers a conflict on the PINS of the Y driver, which is aggravated with certain elements which affect them, such as MKS_UI, PWM...

[makarenya]

I can see

• FSMC_NBL1 on Y_EN
• FSMC_NBL0 on Y_STEP
• SDIO_D5, TIM4_CH4, I2C1_SDA on Y_DIR

other functions not very interesting

[Sgt-Sasquatch]

I can see

• FSMC_NBL1 on Y_EN
• FSMC_NBL0 on Y_STEP
• SDIO_D5, TIM4_CH4, I2C1_SDA on Y_DIR

other functions not very interesting

so what we should do right now about MKS robin nano 1.2 ? i still have layer shift . do you have a the latest solved firmware ?

[mjbogusz]

The workaround for now is to just use ColorUI. It may not be as pretty but it's functional and it works.

[makarenya]

I can see

• FSMC_NBL1 on Y_EN
• FSMC_NBL0 on Y_STEP
• SDIO_D5, TIM4_CH4, I2C1_SDA on Y_DIR

other functions not very interesting

so what we should do right now about MKS robin nano 1.2 ? i still have layer shift . do you have a the latest solved firmware ?

replace Y and E1 axis. It solve problem for me. You can change it in https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/Marlin/src/pins/stm32f1/pins_MKS_ROBIN_NANO_common.h and move driver and cable physically

[mjbogusz]

Bumping. Could we have something like no-stale label so the bot won't try to close this issue? It's not going away on it's own and it at least serves the purpose of being a warning for people trying LVGL on MKS Robin (and possibly other boards)

[franmuzi1]

same bug on mks robin nano 1.3 and marlin 2.1.2.1 bugfix

[mjbogusz]

Bumping.

This would not be needed if anyone could reopen an issue closed as stale...