[BUG] Randomly M21/M1

[Randwic]

Description

M1/M21

Steps to reproduce

1. Try print with Sd TFT port
2. Try print with Isb TFT port

Expected behavior

No print error

Actual behavior

I have M21 or M1 errors randomly when printing ### Hardware Variant TFT 70 V3.0 ### TFT Firmware Version & Main Board Firmware details TFT 3.27.0 and Marlin 2.0.9.2 ### Additional Information * Hello, first i'm sorry for my english but i'm french and again sorry if i'm in the wrong section but this is the first time i've used a request on github. I recently installed on my FlSun super Racer a Skr v2 card and a Tft70 from Biqu. However since that time I have had bugs in my printing sometimes the printer stops with the M21 error or the M1 error without having configured a pause in the Slicer. It has also happened to me that printing stops without error on the TFT. I have tried printing with the SD card as well as the USB from the TFT but I have the same concerns however I have no problem securing the USB stick on the motherboard. I have the latest version of TFT as well as the latest version on the motherboard would you have any idea of ​​the problem thanks in advance.

[oldman4U]

This is most likely a SKR problem and not a problem of the TFT firmware. Please update the title to something meaningful and close the ticket once you do not need it anymore.

Thank you

[Guilouz]

@oldman4U Nope it's also happen with Artillery Ruby motherboard.

No issue with same Gcode when printing from motherboard port or with Octoprint. And no issue with official release from April 10. And M1/21 happens randomly when printing with the SD or USB port of the TFT.

It seems that is recent PR cause this but impossible to find it.

This is what I have already tested without success :

• Use shielded cable to connect the RS232 port of the TFT to the motherboard
• Only use one serial port P1 in config, all others are disabled
• Also try to disable Emulated M109 And M190 settings

[radek8]

If you are using a high-speed serial port, try reducing the port speed to 115200. Lay the serial cable between the SKR and the TFT as far as possible from the stepper motors and the TMC controller. Be sure to use a shielded serial cable! This is interference that occurs on the serial cable, damaging existing communications. I used to have a similar problem. TFT sent to Marlin code M105, but Marlin received M10 and M1. Take a look at the serial line communication errors here: https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/1297

[Guilouz]

@radek8 But how do you explain that with the same hardware configuration but with the official TFT firmware in release section the problem does not appear?

And for M21 ? Do you think that it is possible that this comes from the fact that the screen does not support the MULTI_VOLUME function of Marlin. I have tried with MULTI_VOLUME enabled and disabled with USB SUPPORT enabled.

And as already said I already use a shielded cable (on your advice).

[radek8]

I don't know. Is it a distorted M221 command? In my case, the M105 was damaged in format M10105, M1, M10N105, M1005, MM105 ...

Do you have the option to log communication and, in the event of an error, check which commands have been sent and received? This would help a lot to find where the problem came from.

[Guilouz]

How I can check the communication? Because this only happens when printing from SD or USD TFT.

[radek8]

My problem arose a year ago also after some update. But the update did not have to damage the FW. Could it be enough that the frequency of sending the M105 command changed and this could have an effect on the error rate? I don't know, it's just my estimates. After replacing the shielded cable, the problem was solved. So the problem was not directly in the FW, even though it appeared after the update.

[radek8]

I connected WiFi to TFT. Then I connected the printer as a virtual serial port to a PC and monitored the communication in Pronterface. But this is how he will see what TFT is sending and what Marlin is answering. He won't see what Marlin actually accepted. But maybe that would be enough.

You will need to compile New FW with enabled

define DEBUG_SERIAL_COMM

and the set port number you will monitor (for example WIFI port 2).

[radek8]

It would be better to watch Marlin, but I don't know if Marlin sends serial communication to all ports, such as USB. Then it would be enough to connect via USB to Pronterface and start printing from TFT. He would like to try it.

[radek8]

Debug Communications must be enabled in Pronterface

[kisslorand]

I have this M21/M1 issue also. It appeared only after my SKR v1.4 Turbo died and switched to SKR v2. More than that, my BlTouch deployed randomly during print. I had none of that with SKR v1.4 Turbo. It happened on a Artillery SWX1 printer. What I did is, I rearranged the cables/pins so the "servo" signal is now wired in the ribbon cable so it sits between a VCC and GND wire so it is shielded at some degree. No problems with random BlTouch deploy since then. I also replaced the ribbon cable between the TFT and the SKR v2 with a shielded cable but without positive results. It is enough just to power on my printer and let it idle. At random times I have a popup telling me "SD init OK". It is the response from Marlin to M21. Beats me...

I was thinking about removing M1 from my Marlin...

[Guilouz]

@kisslorand I have also SKR2 but some builds from master work perfectly, up to a certain PR that I can't identify.

[radek8]

The TFT sends M220 and M221 commands at regular intervals to update the status. This command on M1 or M21 is most likely to be corrupted. The strange thing is that SKR2 owners are complaining about this problem.

[Guilouz]

@radek8 Also Artillery Ruby owners on Sidewinder X2

[kisslorand]

What MCU is on this Ruby?

[Guilouz]

@kisslorand STM32F401RCT6

[kisslorand]

So it's the same family, 32F4xx.

[Guilouz]

I think it's not related to this because with latest Marlin bugfix and TFT official release firmware there is no issue, only with master.

[kisslorand]

The TFT sends M220 and M221 commands at regular intervals to update the status. This command on M1 or M21 is most likely to be corrupted. The strange thing is that SKR2 owners are complaining about this problem.

What could make only these messages to get corrupted? I was watching my printer with Pronterface, I saw no "Unknown command". How can messages to get corrupted only to good commands?

[Guilouz]

@kisslorand Yes I do not understand either, if there were corrupted commands it will be the case of several commands, while the prints are perfect, no temperature drops or whatever.

[radek8]

Can't it also matter how Marlin and the MCU use Buffer? Can you try to change some Buffer values and test if this doesn't solve the problem?

[Guilouz]

@radek8 This is config buffer I use :

// The number of linear moves that can be in the planner at once. // The value of BLOCK_BUFFER_SIZE must be a power of 2 (e.g., 8, 16, 32)

if BOTH(SDSUPPORT, DIRECT_STEPPING)

define BLOCK_BUFFER_SIZE 8

elif ENABLED(SDSUPPORT)

define BLOCK_BUFFER_SIZE 64

else

define BLOCK_BUFFER_SIZE 32

endif

// @section serial

// The ASCII buffer for serial input

define MAX_CMD_SIZE 96

define BUFSIZE 32

// Transmission to Host Buffer Size // To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0. // To buffer a simple "ok" you need 4 bytes. // For ADVANCED_OK (M105) you need 32 bytes. // For debug-echo: 128 bytes for the optimal speed. // Other output doesn't need to be that speedy. // :[0, 2, 4, 8, 16, 32, 64, 128, 256]

define TX_BUFFER_SIZE 64

// Host Receive Buffer Size // Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough. // To use flow control, set this buffer size to at least 1024 bytes. // :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048] //#define RX_BUFFER_SIZE 1024

[radek8]

You have higher values than my settings, which can reduce your free RAM. Is that so, or am I wrong?

My settings are this.

// The number of linear moves that can be in the planner at once. // The value of BLOCK_BUFFER_SIZE must be a power of 2 (e.g., 8, 16, 32)

if BOTH(SDSUPPORT, DIRECT_STEPPING)

define BLOCK_BUFFER_SIZE 16

elif ENABLED(SDSUPPORT)

define BLOCK_BUFFER_SIZE 16

else

define BLOCK_BUFFER_SIZE 16

endif

// @section serial

// The ASCII buffer for serial input

define MAX_CMD_SIZE 96

define BUFSIZE 16

// Transmission to Host Buffer Size // To save 386 bytes of PROGMEM (and TX_BUFFER_SIZE+3 bytes of RAM) set to 0. // To buffer a simple "ok" you need 4 bytes. // For ADVANCED_OK (M105) you need 32 bytes. // For debug-echo: 128 bytes for the optimal speed. // Other output doesn't need to be that speedy. // :[0, 2, 4, 8, 16, 32, 64, 128, 256]

define TX_BUFFER_SIZE 16

// Host Receive Buffer Size // Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough. // To use flow control, set this buffer size to at least 1024 bytes. // :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048] //#define RX_BUFFER_SIZE 1024

if RX_BUFFER_SIZE >= 1024

// Enable to have the controller send XON/XOFF control characters to // the host to signal the RX buffer is becoming full. //#define SERIAL_XON_XOFF

endif

[kisslorand]

0100 1101 0011 0001 0000 1010 - "M1\n" 0100 1101 0011 0010 0011 0001 0000 1010 - "M21\n" 0100 1101 0011 0010 0011 0010 0011 0000 0000 1010 - "M220\n" 0100 1101 0011 0010 0011 0010 0011 0001 0000 1010 - "M221\n"

These are the binary form of M1, M21, M220 and M221 commands. The difference is too much between M1/M21 and M220/M221.

I use the same buffer settings as I used for my SKR 1.4 Turbo with a MCU (LPC 1769) that has less of everything than 32F407 (SKR v2).

@kisslorand Yes I do not understand either, if there were corrupted commands it will be the case of several commands, while the prints are perfect, no temperature drops or whatever.

Exactly my thoughts too! If there's corruption it must show itself in more situation but it is always M1 or M21, absolutely no other misbehaviour. Sadly I couldn't catch neither of them with Pronterface. For the moment eliminating M1 from my Marlin is the only (temporary) solution. M21 doesn't do any harm during print.

[Guilouz]

@radek8 With my settings VSCode report :

RAM: [== ] 20.4% (used 26728 bytes from 131072 bytes) Flash: [== ] 22.0% (used 230200 bytes from 1048576 bytes)

@kisslorand Did you just remove " void " from Marlin?

[kisslorand]

@kisslorand Did you just remove " void " from Marlin?

Nope. There are several ways to do it.

• in M0_m1.cpp:

  void GcodeSuite::M0_M1() {
  return;
  ...

• in gcode.cpp:

  case 'M': switch (parser.codenum) {
  
    #if HAS_RESUME_CONTINUE
      case 0:                                                   // M0: Unconditional stop - Wait for user button press on LCD
      case 1: /*M0_M1();*/ break;                                   // M1: Conditional stop - Wait for user button press on LCD
    #endif

[Guilouz]

@kisslorand I have disabled M0/M1 in Marlin, M1 command is now unknown from host (Pronterface) but always enabled when is send from TFT Terminal.

I think it is also necessary to disable these functions on the TFT side as well.

[kisslorand]

I just tested it. When M1 is captured by the TFT (from gcode file or from terminal manual enter) the message is different than when you send M1 from Pronterface to Marlin. The messages I was getting are the ones that comes when Marlin receives M1.

In the meantime I discovered a bug, during printing I sent M1 from terminal, print paused and when I hit resume the nozzle went into the bed and print continued. I have a nice scratch now... The same happens if you have M1 in your gcode file. So one thing is clear, M1 is not received by the TFT (not from gcode file, not from the motherboard).

[Guilouz]

Yes when M1 is sending by host we have a popup "M1 Stop" with choice to continue or to cancel. When it's sending from TFT Terminal, just a "pause" popup with one finish button and need to click to Resume button on printing screen to restart print.

Do you think if it's only removed from Marlin it will be good ?

[kisslorand]

I don't know about others but I had only the "M1 Stop" poupup, not the "pause" one.

[DCib]

I have the same "M1 Stop" commands pop up that pause my print or click the screen to continue. Mine also happen whether I'm printing or not. Doesn't that mean it cant be the buffer size in marlin and is something else ?

[kisslorand]

Yes, it is most probably something else but for the moment there's no clue at all where to look for the source of the problem.

[kisslorand]

Doing some further investigation, it seems it's the TFT that sends M1 and M21 to Marlin. Marlin responds to these only on the serial port it receives it. So if I send it from Pronterface (serial by USB) I get response only on Pronterface. Still looking for the cause of it...

[kisslorand]

I found a possible fix. For those who want to try replace line 70 in "SpeedControl.c"

speedQueryWait = storeCmd("M220\nM221\n");

with:

speedQueryWait = (storeCmd("M220\n") == true) ? storeCmd("M221\n") : false;

[Guilouz]

I will try.

But not understand because M220 is to control Feedrate percentage and M221 for Flow percentage.

[kisslorand]

The idea is to send them separately not together. It's just a hunch, I am not sure that this is the source of the problem.

[Guilouz]

It’s a confirmation that M1 is sent by TFT. Here popup message with M0/M1 disabled in Marlin. Command try to be send.

[kisslorand]

Did this happen with the modifications suggested by me?

[Guilouz]

No not tried yet

[ACNC88]

I also have this problem after upgrading to SKR mini E3 V3.0. I am using a TFT35 v3.0. The issue started after I swapped JUST the controller board, which makes me think the problem is with the board not the display. I have updated the firmware on both motherboard and display but the problem is still there (randomly).

[elgroso52]

Same problem for me after switching from an SKR miniE3 V1.2 to an SKR miniE3 V3.0. with a TFT35 V3 E3.

[digant73]

As suggested by kisslorand, if splitting M220 and M221 in two different transmissions solves the issue it is possible that the mainboard is not reading and buffering the whole "M220\nM221\n" in one shot. So after processing M220\n and sending back the reply to TFT, the TFT will also set infoHost.wait to "false" (once "ok" is received from mainboard) so the next gcode of the print file is sent to the mainboard while the mainboard will try to read M221\n. That could be the explanation of the issue. With the exception of another multi-command in MachineParameter menu (MBL command), there are no other multi-command sent with storeCmd function (all the other multi-commands are sent with mustStoreScript function that will split the commands in multiple transmissions)

[kisslorand]

The problem is not only during print. If I turn on my printer and leave it on idle than at some point I will get a response from M21 (SD card OK). I even bought a second SKR 2, this one with the 429 MCU and the problem persists. I have to mention also that I never encountered such problems with my previous MB SKR v1.4 Turbo which I sadly broke.

[digant73]

do you have the issue even splitting M220 and M221? I also had a look to Marlin and all the stream is read and buffered from the serial port in one shot

[kisslorand]

I haven't had the chance to try with M220 and M221 separated. My test rig is with MKS GEN_L (Atmega 2560) and I haven't seen the issue there. I just swapped it out with SKR v2 (STM32F407) and I want to check if the M0_M1 & M21 issue will be present on that test rig.

[digant73]

if I'm not wrong, I had similar issues in the past with MKS GEN L using the default values:

define BUFSIZE 4

define TX_BUFFER_SIZE 0

and I solved that issue using the following settings in Configuration_adv.h:

define BUFSIZE 16

define TX_BUFFER_SIZE 16

With those values I never had any issue

[kisslorand]

I left my test rig powered on (TFT35_V3 + SKR v2) for several hours and I got an M21. After that I enabled DEBUG in the TFT's FW and watched it for a couple of hours.

By enablin DEBUG in the TFT's FW I see this:

>>M220
M221
<<wait
wait
<<FR:100%
FR:100%
<<ok P15 B15
<<echo:E0 Flow: 100%
echo:E0 Flow: 100%
<<ok P15 B15
<<wait
wait

With the changes I suggested I see this:

>>M220
<<FR:100%
FR:100%
<<ok P15 B15
>>M221
<<echo:E0 Flow: 100%
echo:E0 Flow: 100%
<<ok P15 B15
<<wait
wait

I really do not know if it makes a difference but it seems a cleaner communication, one command, a response, an "ok" than comes the next command.

In 2 hours of watching the output there was not a single M0_M1 or M21 issue so I couldn't catch anything.

[kisslorand]

After more than 12 hours with the M220 and M221 separated, there's no sign of M0_M1 nor M21. I am keeping the test rig on and logging to a file all serial communications.

[V1EngineeringInc]

I'm seeing the same issue, and have been through several versions of SKR and TFT firmware on two printers. Many other users have also confirmed this in the V1Engineering Forums.

Random M1, and it seems the newer firmware the Z keeps going, so resuming is no longer an option.

[kisslorand]

So, on my test rig after 24 hours there's still no sign of M0_M1 & M21 bug with M220 and M221 separated. On the other hand I had a 2.5 hours print and while waiting for the bed to cool down M21 appeared on my printer which doesn't have the patch for M220 and M221 separation. (I do not know about M0_M1 because I have that removed from my printer's Marlin) I know it's not a proof of anything but maybe others would like to apply the patch I proposed and come back with feedback.