SKR Pro 1.2 - Program Stopped? How to Diagnose?

TLDR: LR2 stopped after drilling a bunch of holes and then cutting the first of a few parts out. No errors - not sure how to diagnose.

I just finished setting up my LR2, and for the most part, everything seems fine. After doing a variety of testing, i started doing some “real” cuts in 1/2 inch plywood. Using EstlCAM, i dropped in a bunch of DXFs and got the program set up to do some helical drilling and part cut outs. The previews show everything fine - so far, so good.

All in all, the program is doing about 30 small holes and 10 part cut outs in about 14x14 inches of plywood. When i ran it, everything looked good initially. All of the holes were cut without issue, and the first part got cut as expected. It moved over to the second part, then just stopped. There are no errors on the TFT - it just shows 72% done and the timer continued to count up. I waited two minutes, and then stopped the program.

Without any errors, it’s hard for me to understand how to debug it. The G00 to move to the part seemed to work, as did the G01 to move to just above the surface, and then it stopped just prior to beginning the cut out. It doesn’t look like there’s anything weird about the GCode here when compared to the previous successful part cut out.

I’m thinking about cutting out all of the successful gcode and trying to get it to resume. Other than that, are there any suggestions as to what i might do to diagnose it? Does anyone know what kinds of things could cause this? Is there a log file or something of the like that i can access to see if some issue was recorded somewhere? Not sure if there are some hidden options somewhere, but as far as i can tell, such things are not accessible via the TFT.

I am worried there is a handshake problem in the tft. Maybe it misses an ok and doesn’t continue. Can you try the same gcode with the marlin mode or from repetier host? Even if it was an air cut?

Check the 5v plug from the TFT to the board. I had a similar issue and noticed the 5v pin was not very secure due to me moving the screen in my mock up box. After putting strain relief on the cable i stopped having issues.

2 Likes

Thanks for the response. I have run the same program again without issue, so i guess for now i’ll do nothing and hope that helps! I have noticed that the 5v pin was indeed a bit loose. Maybe i’ll put a little dab of hot glue on it to keep it in place. The other connectors with the screen are totally secure.

I’m running another program now (to cut new Y plates that will hopefully correct an unrelated issue). Fingers crossed that this finishes without issue!

Speaking of “misses an ok”, my screen shows some alert right after starting a program, but the alert pops up BEHIND the other icons on the cut menu, and thus i can’t actually read it. So i have no idea what it says. Is this expected?

I’m also consistently getting an “Unknown command M05” popup at the end of every program. I can see this in the gcode, and i understand that this is a spindle off command. Is it possible that the hidden first alert i’m getting is in response to a M03 at the start of the gcode? Maybe there’s a setting in Estlcam to turn these off. I’ll go look…

It’s with regards to the spindle speed. Just look at your code in estlcam and comment out that line. The one error is for turning the spindle on and the other error is for turning the spindle off at the end of the program. I had the same issue. I actually had issues when running the black and grey cables together on the screen as well and am now just running the black cable by itself. With regards to running the same program without an issue. Mine did the same thing and hasn’t happened since securing the 5v better

Nope. I wonder if it is complaining about an M3 command, since you have the M5?

My guess is that this is a race condition and the message gets caught and shown before the menu changes to the in progress screen.

Yes it is the M3 command that comes up due to the start code in estlcam

I had this problem a few of times while using the touch interface on the TFT35. Secured everything with hot glue and it was still happening. It must have had something to do with the connection or the touch software itself. Once I switched to using Marlin mode exclusively it never happened again.