Marlin
Marlin copied to clipboard
MarlinFirmware
[BUG] TFT_LVGL_UI (MKS_UI): Y axis motion loss / offset, does not occur with TFT_COLOR_UI
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
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.
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.
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 !
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.
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
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
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 .
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.
Se problem here MKS Robin nano 1.2 TFT_LVGL_UI. Custom built based on BLUER configuration source.
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
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.
I have this problem too. mks robin nano v 1.2, Marlin 2.0.9.3, LVGL UI (MKS UI)
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
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
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.
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
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 default_envs from mks_robin_nano35 to mks_robin_nano35_maple i don't have this problem any more.
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.
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.
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.
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
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.
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.
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)
Has anyone tried to install the new version 2.1? Has the problem gone away?
mks robin nano v2 tried marlin 2.1 the problem remained! when will you fix it?
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
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.
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.
very interesting what you saw with the interaction with the fan/laser. Are you using software or hardware fan pwm?