Help….Totally frustrated here with my LR3 build with the firmware’s. Typing this all out to get out of my own head, and maybe someone will see my issue for me. Can’t see the forest for the trees and all. I am seeing on posts that this should be working, but it isn’t.
I am running the SKR Pro and TFT screen. I have them from a friend that is building a MPCNC but I got ahead of him. He wasn’t going to get to the project anytime soon it seemed so let me borrow these for my setup. Not sure where he got these, it wasn’t from V1, so I need to flash them with V1 LR firmware.
The problems are the following:
- Can’t home X and Z, motors run to the home switch, press it and keep on going.
- Y homes just fine, but then gives me a M420 error.
- Z axis some times ignores the single step command that was given and just runs to the end of its play and crashes. Happens in moves going either direction. X seems to honor the moves it was asked to do with no issues.
I assume all of these are firmware related, but I believe I am on the latest firmware for both. Some of my troubleshooting steps.
- I believe my home switches are all working as expected. I have used the M119 command and stepped through all 5 of them. They are wired per the instructions as normally closed. The screen reports the switches as open if I don’t touch them and triggered if I press them in manually. They also are reporting for the correct place on the machine, Y1, Y2 and such. Doesn’t make sense that the X and Z are ignoring the home switch getting pressed and Y works fine.
This goes to a list of firmware for all the different cards and I have specifically used this download - https://github.com/V1EngineeringInc/MarlinBuilder/releases/download/515/V1CNC_SkrPro_DualLR_2209-2.1.1.zip
Not sure why, but I have to run the flash process twice for the card. Boot the card with the gray cables for the screen unplugged and the SD card install, the light flashes green for a second or two and then goes out. The firmware is still called firmware.bin. Power the machine off and back on and the process with the green light is the same, but this time the firmware file has been renamed to firmware.cur. I assume based on that I am running the latest needed firmware for the card.
Based on this thread, New TFT release, this firmware should be the fix for my M420 after homing error, but it still happens on the one axis that I can home.
I have been building based on the instructions here - LowRider CNC V3 - V1 Engineering Documentation. At this point I don’t know what to do next. I should have the latest firmware for both pieces, but still have issues. To me the hardware seems to be ok as the homing switches all work, motors run fine and such, but maybe I am wrong and I need to replace one or both of them.
Going to feed the goats now and try and get this out of my head.
Try the non GD version of e3 v3.
Something is fishy but start there. You also the the folder and config file. The screen does show the right stuff so it has been flashed at some point.
Can you show a screenshot of the M119 screen.
How are you homing?
Hello @ZzingG! I appreciate the detailed writeup of what you’re seeing and tried. As time consuming as that is, personally I find writing out problems like this helps clarify what’s going on.
RE1: Not sure what to suggest here, you’re using M119 and manually confirming the switches are working, this is what I’d do. Consider running M119 a few times, do you see consistent output? What gauge wire is between your endstops and the board? How wide is your gantry? Unlikely cause, but we’ve seen issues with SKR Pro 1.2 boards not correctly detecting endstop state.
RE2: M420 might be ignorable, expecting someone will confirm… Already seen Measuring AXIS on table LR3 - #38 by vicious1 ?
RE3: Have personally encountered many Z movements that weren’t what I wanted, but were what I commanded… Sometimes I’ve forgotten to Z home, or manually set the Z position G92 Z0 by manually probing, or using a touch probe G38. Other times there’s been a mismatch between my intent and what I told the machine to do because movements were configured to be ‘relative’, or ‘absolute’.
- Can’t home X and Z, motors run to the home switch, press it and keep on going.
First, I’d run your display in Marlin mode by holding the knob down for a couple of seconds, then reboot the board and verify the right firmware is on the board. Alternately, you can send an M115 to get the firmware info. I just want you to verify that you have dual Lowrider firmware on the control board.
Second, as Ryan suggests, post a picture of your M119.
Assuming the firmware and M119 check out, then it looks like you have a control board issue. There is a design weakness in the SKR Pro that, when combined with out of spec components, results in problems detecting the limit switches. This is the topic where the issue was first identified, and there are several other topics on the issue. This issue is rare, but common enough to generate several topics on the forum.
Your choices are 1) exchange the board for a new one, 2) disconnect the LEDs associated with the limit switches by either unsoldering them or cutting their traces, or 3) add a pullup resistor for the limit switches. Most people add the resistors. It can be done destructively by soldering the resistors. This post shows how it can be done. It can also be done without modifying the SKR Pro board. Here is a post where the resistor was added to the wiring.
Can you please post a picture of your TFT‘s main processor. It will help to select the right TFT firmware file.
The M420 should not show up with the latest TFT firmware. Have you checked the file extensions after flashing? The same logic applies as for the board, ie you should see *.cur extensions for the screen files as well after a successful flashing.
The buttons you see are what they should be. Some of us have modified the firmware to make it more usable for CNC, this is what you may have seen on youtube / pictures.
Thank you all for the tips here. I have figured out the homing issue. All the comments got me looking at it differently and it turns out that I had mixed up one Z and the X home switch. Once those were correct all axis started homing correctly. I did as @azab2c state above and ran M119 a bunch of time on the different sensors and they all triggered correctly each time.
Here is a shot with Y homed and then moved away from the switches. I assume this is normal responses for these at this point?
I am now getting the M420 on all axis after they are homed. If I understand this correctly it is a TFT screen issue over the controller card?
Here it is. I was use the GD firmware due to the GD in first line on this.
I tried the following files and still getting the M420 error
I have the TFT35 and config file on the SD card as well. Both of these get the .cur added to the end after the screen has been flashed. The firmware doesn’t get renamed after a flash. Here is the screen shot of the firmware on the info screen. I don’t think that this has changed as I have done different screen firmware, but maybe this is expected as I have just done different flavors of V27?
In regards to Z axis ignoring movement command, I have just been using the movement options from the screen at this point, so whatever that process uses is what is done here. I do see that for some reason the Z axis is at 200mm position. But I don’t see a way to re-zero the axis. This setting is also being stored over reboots of the card. That isn’t really expected and I figured it would reset after power offs. I wonder if this is the issue in some way?
Thanks all for the help to this point. Feeling much better now that some items are working better.
Home Z, then use a touch plate to have top of your stock set as Z axis 0mm position. Already seen this helpful CNC workflow video?
If it doesn‘t get renamed, it will not have properly been flashed.
I‘d say: Yes. You are probably still using an outdated firmware version
GD is correct. It is a GD processor. You can copy all GD firmware files to the SD card, the screen will pick the proper one.
I think Bigtree/Ryan don’t increase the version numbers, so they are all V27s. But I am a bit confused by the date 15 Feb 2023. I really don‘t know what my screen showed, but the latest firmware dates 23 March 2023.
My conclusion would be that you are still using an old TFT firmware version.
Just guessing here, but I would bet that it’s that Z2 switch goees to X_Max, so I’d figure you put Z1 to X_Min and X to Z_Max (Z_Min going to the touch plate.) It’s pretty easy to see that happening, because you group the Y switches that way.
The M420 error is with the TFT, kind of annoying but not a show stopper. You should still be able to run gcode, so let’s see that test crown!
Woot, some more good news,
Yes, I don’t think the screen is fully flashing for some reason. I copied all the files from the screen firmware zip file to the SD, per your comments as well and let it pick what it wanted. All three items are now tagged with the .cur. The firmware it picked was the BIGTREE_GD_TFT35_V3.0.27.x Still getting the M420 error and the firmware version screen I showed above still looks the same. Still that Feb 15th date,
This is probably closer than I would like to say. I would have sworn on a Bible in a court of law that I had those switches correct. But that was as much of a problem as the switches being wrong. I did not go back and double check until the questions prompted here because I was SURE it was correct, but they weren’t.
On the plus side, I have a crown.
Figured it wouldn’t hurt to at least try. Hadn’t seen that cnc workflow video yet, so watched it and gave it a try. This is print on a slab of plywood so the marker bleed with the grain.
Will probably print this a bunch more, just cause I can. but need to now confirm square on the machine. Have a router on order and will get that installed and cut up some foam for the next stage of testing.
Would really like to get that M420 error cleared, but like has been stated it does work and that is just a bit of annoyance.
Thanks all for the help with this.
The date displayed is the date/time the firmware was compiled. This is the source code producing the line:
sprintf(buf, "V"STRINGIFY(SOFTWARE_VERSION) " " __DATE__ " in %dMhz", mcuClocks.rccClocks.SYSCLK_Frequency / 1000000);
I also find it quite strange that it says ‘BIGTREETECH_ …’. It should read ‘BIGTREE_ …’ instead, given the settings in platformio.ini:
So, either you picked the wrong file (which I would rule out as I double-checked the link you posted above), or the firmware file included in the ZIP package is old and/or being compiled in a different/wrong environment.
You can verify this by compiling the sources yourself, using the branch ‘CNC_Version’.
Or you try this one, just freshly compiled from the latest sources:
BIGTREE_GD_TFT35_V3.0.27.x.bin.zip (124.0 KB)
Thanks for compiling that, not sure I could have done it. I used the same SD card I used last time. I deleted the current firmware file that had been renamed to .CUR and then renamed the TFT35 directory and the config.ini file to remove the .CUR. Ran the the flash process and the screen did the different steps I am used to seeing at this point.
The SD card now shows both files and the directory now have the .CUR ending. Firmware file was renamed as well. Info screen still showed the same. Just to make sure that the correct firmware file was used I deleted all the firmware files form the card and only put the one linked and ran the flash again. It ran the process again and all items were now renamed ending in .CUR
Same outcome. Here is a screen shot of the info screen.
Could there be something with the config.ini or TFT35 file/folder that is being used? I was looking at the config.ini and there is a reference to BIGTREETECH in it in three places, but those are comments in the file from what I can tell. Here is one example
# Firmware source: https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware
But my experience that ‘#’ makes the line a comment.
Hmm, that’s a strange one. The flashing procedure starts and terminates, renames the firmware file to *.cur, but - hasn’t really flashed the firmware! The screenshot proofs that the old firmware version is still running.
Don’t think so, but please post a picture of the SD card directory before flashing. Maybe also post a picture what the screen shows during flashing it.
Correct, that’s a comment.
So, a couple of points to check:
Try to hard reset the screen: Use a blank SD card and copy an empty file ‘reset.txt’ to the SD card. Boot the screen with the SD card inserted. Your file should be renamed to ‘reset.txt.DONE’. Then try to flash again.
What kind of SD card are you using? People have reported issues with larger SD cards. Use the smallest / oldest you can find. Bigtree say it should be less than or equal to 8GB and formatted as FAT32.
Can you please also post a picture of your entire tft board from the top/front, including the writing below the tft panel.
Sorry for the delayed response, had to move a load of hay yesterday in 102 temp and think I got myself a bit of heat stroke and didn’t feel up to doing anything after that was all done.
Got to looking at these and doing the steps this morning and something different has happened. What is the difference in the firmware process between a power on and a reset?
I was going to get fancy and was setting up my phone to record the screen and show the different steps that I was doing as well as the screen as it worked. Due to the phone setup on the tripod and where I needed to be to work on the screen I was just out of reach of the main power button for my LR for this. Due to this I did a different flash process than I had in the past.
I installed the my 2GB SD card (this is the same card I have used for all of this) into the side of the machine and then hit the reset on the screen. I have never flashed the screen in this way in the past, Different things happened with this reset process. I saw the following screen this time, that I don’t believe I have seen before.
If it was there before it happened so fast I didn’t see it between hitting the power and looking back at the screen. This time I was able to watch the updating percent count up. Normally it started with this process on the screen as the first step.
and I know have a firmware info screen that is different from what has happened so far. I think this is what is expected now.
Not sure why it worked with a reset over a fresh power on cycle? Did I miss a step in this flash process and have been doing it wrong the entire time?
Some extra items that might have had an impact as well. To prepare for the screen shots of my SD card being used and what was on it I formatted the card with a quick format and recopied over the files. This is faster than deleting everything that was on it, it had the entire CNC_TFT.zip unzipped onto it. The files were then copied back over to it. The TFT35 folder, the config.ini as well as the last firmware linked above only. I had created a second SD card for the reset process but haven’t used it yet. I was going to flash with the firmware again as a test before the reset. Since it worked I didn’t do that step. I suppose it could be that there was something odd with my SD card and that format cleared the issue as well.
I can now home and not get the M420 error. woot woot.
Yes, you have managed to flash the firmware I compiled for you on 23 Jul 2023!
Congratulations! Glad it works for you now. Just do it the same way next time
Just a follow up regarding the SD card.
I have found that just deleting files doesn’t really “clean” the SD card.
I also find that the SD Card Association formatter seems to do a better job of “resetting” an SD card as new : https://www.sdcard.org/downloads/formatter/