I have the SKRPro 1.2 dual endstop with BTT TFT Bigtree V3_E3.27. I realized 2 hours (80%) into a roughing cut into very nice walnut that the Carveco software was having it mill out the entire perimeter during roughing (Dumb as that would free the model before Finishing pass… Not sure yet how to fix that issue).
At any rate, I hit the pause button on the TFT35 so that I could apply some kind of fix (screw through the back of the spoil board? IDK) … That is when I learned that the PAUSE button causes the router to immediately return to 0,0 WITHOUT raising Z!!! WHY??? It ripped right through the project given the fact it was working deep on the perimeter when I paused…
HOW DO I FIX THIS? Is there a way to reprogram the button so that it merely stops motion in the XY plane and raises Z, and STOPS?
Certainly others have run into this- Welcome thoughts and ideas from those more experienced?
Ouch! That’s frustrating, to be sure, and I can see where you’d be upset. Sadly, this is still a case of a dumb machine doing exactly what it’s told to do. You just didn’t mean to tell it to do that.
Normally, I’d agree with your basic premise, but it’s more complicated than that. I think it might be better to stop X,Y motion, and allow the operator to make any spindle/Z changes on their own. Mainly because if you’re going to restart the job, you need to go back to the exact same spot you stopped. So having the operator responsible for knowing you raised the bit N mm, you’re then responsible for lowering it N mm before resuming the job. Yes, I’m sure there are a number of ways to store the current position, then move the bit up and out of the way, and then return it before resuming, but I’m not familiar with any of them off the cuff. (One that springs to mind would be to utilize workspace coordinates, but that could get ugly.)
Regardless, just want to let you know you’re heard, and your frustration and anger are valid. Hopefully, someone with real experience and know-how will be along who can help you out (or help you through, depending on their particular experiences).
Ouch! Sorry to hear. That is strange because whenever I hit pause it stops at the last position like @kvcummins is thinking. But I’m using an older firmware (512 or 513 I believe) so maybe the Pause functionality has broken with one of the updates. Hopefully someone else with a newer FW can chime in.
Very much agree- just pause. I swear my old firmware did just that, but I had a probe issue that led me done a rabbit hole of reflashing my board to verify. 515 yesterday… All seemed good for hours, and then PAUSE sent the bit straight home!
Hoping someone can at least help learn or improve my setup as some kind of silver lining.
That is strange behavior. I have used the pause button several times in the past (very infrequently) for similar reasons and never had that happen. Curious what you find
Might be the newer firmware… I’m running an older version. Don’t remember which version off the top of my head
I just did a bit of research. First, on my Rambo board, pausing a job does not cause the tool to be parked. It just stopped at its current location. Looking at the Marlin source, there is a feature enabled by the define ‘PARK_HEAD_ON_PAUSE’ that will move the head to a park location on a pause. This feature is not enabled in the V1 maintained versions of the Marlin firmware.
When I look at the TFT source (and I just dipped my toes lightly in the source), it appears it executes ‘M25 P1’ for a pause. Looking at the Marlin g-code reference, the ‘P’ parameter is not documented. My theory is it forces the tool to park.
You can easily test my theory. Run a job (in the air is fine), and pause from the TFT. It should park the head. Next run the job in Marlin mode on the display (hold the knob for a couple of seconds to put the display in Marlin mode). Run the job and pause, and see if the head is parked. I’m betting that it will not be parked (assuming you are running V1 maintained firmware).
A note about pausing on Marlin. Pauses are placed in the command queue just like all other g-code commands. They are executed when they come to the front of the queue. If your job is working on some sort of arbitrary curve, then the pause will happen almost immediately, but if your job is working on long, straight cuts, it can take some time for the command to work itself to the front of the queue. So, for the tests in my previous paragraph, a curvy job might be better.
Edit: I looked around a bit more. I didn’t find any Marlin code to process a parameter for M25. It is possible that the TFT is sending an M125, but I could not find any place where an M125 was being sent by the TFT code. There is a place for an M25. Are you running V1 maintained firmware?
For what it’s worth, because I was running an older V1 firmware on an SKR Pro board with a BTT TFT35, whenever I would pause a job, it would park the core, but I never ran into that kind of issue. I think mine was raising to the Z “safe height” before parking. I think the Z “safe height” gets set “per job” by the software creating the G-Code? (And perhaps there is a default if not set? Not sure.) Can you please check that (1) you have a Z “safe height” being set, and (2) what height is your Z “safe height”?
Sir- You were correct. I performed your test and confirmed that the TFT Pause once again sent the bit home, while performing a pause in MARLIN mode did NOT… In Marlin Mode it simply paused the way you would expect (albeit with a short delay due to queue)…
Yes, I have only used V1 firmware to date, BUT I would like to start diving into the BTT TFT Firmware to tailor it for my needs- and fixing this homing issue for starts. As you seem to have a good handle on the TFT code layout, any thoughts on further testing or code mod to fix this? I see where to modify pause in gcode.c request M25, but I would acutely like to tailor the icons, functions, and cut out more of the 3d printer related interface as well.
Thanks again to everyone that responded to this thread, I feel like I’ve learned more and hopefully identified a path to fix this bug.
I have very little knowledge of the TFT Firmware. I’ve just done a bit of grepping to answer a couple of questions on the forum.
I took a test g-code file and inserted a M25 P1 amongst the code. The program paused, but there was no attempt to park. So, the ‘P1’ parameter seems to be ignored by Marlin. The TFT code is sending more than the M25 when pausing, but I did not figure out what/where.
There was no source. I really liked his Icon layout as it was much nicer for CNC work. It also had easy buttons to zero X, Y, or Z based on current location, etc…
I pulled the latest V1 rollup for BTT_TFT code, and I removed the “P1” from the M25 segment of code and recompiled. While it did return the gantry to Home on Pause, it did perform a significant raise on the Z axis first.
GOOD AND BAD: This seems to confirm another user experience pasted in this thread, BUT it still does not perform the desired Marlin ‘Pause’ behavior of just pausing in place. I believe this test also confirms (in a different manner) Robert’s finding that this home-docking behavior on Pause must be coming from somewhere else in then TFT codebase…
Current status:
I will continue trying to track this done to the best of my ability- it would be nice for a Pause to Pause.
I am curious how/why others haven’t gone done this path to tailor the current TFT code base to have a CNC specific Menu. Not even having buttons for Zero X, Y or Z combined with the 3DPrinter related clutter seems like strong motivators in my mind, even if folks are using repiterHost, etc. to generally print from… perhaps this last point is the main reason, but having a simple SD-card Print functionality seems core as one of the other posts above highlighted… Just a thought and curious if my perspective is skewed. Thanks.
Since I don’t use this display, I’ve not followed the post about it closely, but I vaguely remember that, at one time, V1 did reconfigure the display. I think they stopped because of the substantial amount of work associated with reintegrating and testing each time BTT rev’ed their TFT firmware. Note that during the early days of the use of this TFT by V1, there were some bugs in the firmware, including one that caused jobs to freeze.
