Yep, agree. I don’t understand the code 100% either. Removing the ‘storeCmd(“M420\n”)’ makes my problem disappear, so this is definitely where my problem starts.
for some reason yours also sends M420
Are you sure your tft software doesn’t? Maybe it is our Marlin firmwares that react differently on that command from the tft.
…or the screen config
Nope. Definitely not. I’ve checked multiple times, and used your standard config file:
‘auto_load_leveling:0’
I also couldn’t find any sign that my tft software or config are corrupt; the compilation works properly, the software does what I am telling it to do, flash memory is updated whenever I want it to update.
Are you sure your control board firmware does not have bed leveling turned on?
No, I am not. I flashed the firmware for my SKR Pro 1.2 from V1CNC_SkrPro_DualLR_2209-2.1.1.zip months ago and have never touched it since then. Is there an easy test to find this out?
This code is (I think) performing actions based on when the gcode is sent from the tft. There is some stuff at the top related to where the gcode came from. Then a gigantic switch to get only G28.
I agree with Avatorio though. If you’re running this code, Ryan, I would expect it to send M420 whenever G28 goes into the sendQueueCmd. Maybe the G28 X is not using the queue and G28 is? Or maybe there is still some difference between the marlin firmware you two are running.
M420 by itself is not setting anything, it is a query to set the state of the tft to the state of Marlin.
The best way to know for sure is to hook up another usb uart connector on the tx line from the screen to the skr. Then watch what commands go from the tft when you hit the home button.
At any rate, this is a bug introduced 1 month ago. That M420 command should be gated on the bed leveling parameter and it isn’t.
I messed with all my screens yesterday and even a bunch that I flashed for orders. None had any error message when homing, and the headless one shows no errors or any sign of M420 in the terminal window when homing.
Guys, bad news: someone else (a new LR3 maker) has now hit the error of “Unknown command: M420”! Link below. I linked them over to this thread so they could read about the ongoing efforts to solve the issue.
I told them,
Ugh. This is now the second time today I’ve read about someone hitting an error of “Unknown command: M420”! Please check out the discussion beginning at the link below, and continuing onward. (Hint: they are still working on it!)
Same here. No clue how it can happen to one group of people and not to the other.
There is an easy fix for it. This fix - to my mind - is minimum-invasive, but you need to amend and compile the source code of the tft screen for it:
There is a function in ‘usr/API/parseACK.c’ which suppresses specific messages coming from Marlin, i.e. these messages - although posted by Marlin - will not be shown on the tft screen
This function uses the array ‘knownEcho’ to specify which messages should be ignored. Now, if you add the M420 command to this array in line 39 it will be safely ignored:
Interestingly, there are a couple of other entries in this array already dealing with the the M420 command …
This fix works perfectly for me and is not dependant on what BTT / Marlin do with it. It should also work for the Repeat users. So, if this M420 message - for whatever reason - is thrown by Marlin, it will be suppressed. And if it is not thrown, well, then it won’t be shown anyway. The downside is that you will never see this message again on your tft, even if it is thrown by Marlin for a good reason. But I decided to live with this risk.
Alternatively, you can revert the change BTT introduced in Feb (see above). But because I don’t understand Marlin well enough I thought my second option would be better.
I am not super interested in maintaining edits that are that deep. If we can figure out why two of you are seeing this issue, that I can submit it to BTT and get the repo fixed. Always best to get the issue fixed that try to maintain a band aid.
Wondering if more will pop up. Both of you have had other firmware flashed to your screens and BTT does make firmware that is non-down gradable at times. Last time we wanted to go back it caused the screens to show upside down on previously good firmware and could only be fixed with new firmware.
