OK, updated to the newest firmware, both the LCD and SKR Pro 1.2. (CNC.TFT, and 517 firmware)
I run headless.
Ran job before on old firmware (513)/tft. (old v26 dual)
Origin in gcode is centered on material. Also I use a rotary 4th axis sometimes, and I can see this issue will be there using it as well too
When starting a job:
Manually set XYZ (MPCNC off). I use auto-squaring on flat work,lower left origin, and just move the axis with terminal commands to origin, then G92. With the center origin work and the 4th axis, the origin is offset, either for center, or for 4th axis (it is not at auto-square home)
Turn on
Sent via terminal on LCD, G92 X0 Y0 Z0 (absolute positioning).
Start job on Udisk.
Here is the problem…
On start, machine attempts to looking for end-stops, had to manually trip switches to get it to stop. The origin is now off, even with G92 X0 Y0 Z0 command, as after the machine now thinks it is on origin, which it is not.
I use alternate origins quite bit. Any ideas out there?
Did some testing and firmware changes on TFT and Skr Pro. All gcode, air cuts are the same, running off SD card in TFT
TFT firmwares, V.x.x.26-works (July 2020), V.x.x.27 based TFT firmwares do the squaring attempt, and have to be hard stopped.
513D, 511D, 510D, 509D, and older work. 515D in testing with TFT V.x.x.26.
Might just be my TFT’s, I had similar problems when 513 came out.
Is there any chance to get the older, before July 2020 TFT firmwares re-uploaded to the Github, in maybe an archived old firmware repository.
The reason I ask, according to my notes the first firmware I used with these TFTs was V.x.x.23 according to my notes, and they worked the best for me.
With the V.x.x.26 and above they have all been problems, either this or other issues (M221 errors). These 2 TFTs on machines I have are 2-3 years old now, might have something to do with it.
Y’all do good work, I’m just a problem
Did you clear and resave your eeprom? M502 and M500 (from the terminal) or if you dig around in the menus there is a rest or initialize in there somewhere.
Squaring works just fine on the new firmware. I use it daily. The older firmware are still on github but I can tell you the older ones had issues with random crashes and I have never recommended a touch version until this current one.
Have you updated your SKR Pro to match? Both should be updated to the most current firmware at the same time.
I really prefer to help you figure out why this isn’t working for you than have you go back to old firmware. Chances are also good that if you are having this problem others are as well.
Can you tell me exactly what you are doing to get the issue to happen and exactly what happens.
Are you homing from your gcode, a touch screen button, or the terminal? At that point one endstop functions as expected and the other doesn’t? Hitting the home X button on the touch screen should trigger homing of the X axis and autosquaring according to your M666. Same with Y…Z should only be used if you have a touch plate.
Using M119 all endstops show functional? What does M119 say (I can verify your firmware).
Are you sure you loaded the correct set of files? CNC vs Printer? On the SKR pro you loaded the Right firmware MPCNC vs LR? Kinda sounds like you used the wrong base firmware.
Your first post doesn’t really make sense. Setting the current position with G92…and then homing will reset G92 after it homes. G92 does not move your endstops.
Been using this dual end-stop setup for 2+ years. Yes, I got the right firmware files, CNC, not my first update. Used file : /515/V1CNC_SkrPro_Dual_2209-2.1.1.zip from github for SKR firmware. Used CNC.TFT.zip for TFT
M119 all end-stops work.
Firmware info comes back as 517D, and TFT35_V3.0_E3.27. At this point the TFT looks like the sample pics on the github page. As I hadn’t spent a lot of time looking for the "Zero X, Zero Y, and Zero Z buttons, I used the G92 command in TFT terminal to set position (have done this many times before), as the gcode file does not have G92 X0 Y0 Z0 in the start of file, as it is a rotary 4th axis job. Job does not have any G28 commands in it.
Job does not use auto-squaring, also not using homing. Was not an issue on older firmwares
With old firmware/TFT firmware job proceeds as it should. With new firmware/TFT firmware, at start of gcode, the Y axis will try to run to the end stops at start of run and have to be manually tripped before alarm, with 4th axis (X as A) running at high speed continuously, then Z driving into spoilboard.
On old firmware, 4th axis did one slow revolution to cut start, then cut started. Same gcode file for all testing. After re-load of old firmware versions, machine runs as before, behaving smartly, completing rotary job in 12 minutes, running 4345 lines without error.
Did you update the graphics and config files? Everything in the zip file, unzipped first?
515d?
It should not look identical. I have changed the center lower row from stock. it should be 4 buttons across the bottom on boot instead of the 2 and info screen.
Please upload your gcode or at least the first page of it. I can’t think of any reason all three of your axis are homing when you start your file. That should not happen at all.
How are you defining a 4th axis? Did you edit the firmware? How many endstops do you have on the X axis.
First off, I have had these CNC’s since just after the Primo was released, started with series built on 507 firmware.
Rotary axis used is just plugged into X1, with X2 unplugged. low tech, no firmware edits. X is then secured with a clamp each side trapping the trucks, as now they are not driven. No firmware edit or modifications
On the TFT appearance, I didn’t look that close, just noticed theme was the same as on the Github. The config.ini and graphic files, unzipped, were on the SDcard. Only change in the config.ini was knob color to blue.
Oops, you are right 515D.
2 end-stops on the X, 2 on Y. V1 tiny touch plate probe on Z.
Gcode as follows:
I appreciate the clarification, I am not doubting you just covering the bases. I am wondering why there are no other reports of this.
Looking at that gcode I am wondering if that stray 480 is causing the problems. What exactly does the machine do when you start that file? Does it move up 19mm then crash?
The line directly after the stray 480, has the first G1 move with no feed rate specified, and too many spaces, was that edited?
The other issue is you do not have your feed rate defined on every line. That should not be a huge deal anymore but it is still the best practice. So that second line of code is unpredictable in terms of speed.
You have the G92 not happening in your gcode, and you do it manually, is there a reason for that?
Can you test with the test crown to see if your machine crashes when started. That will lead us to either firmware or gcode. There are so many variables here, but the one leading me to believe gcode is no other reports of issues.
Please also double check in the TFT setting that “Start Gcode” is disabled. It should be, but if it is not then the first thing it will do is home X and Y. You said Z also crashes so that should not be it.
“Stray 480” yeah saw that. In reviewing all previous gcode that the CarveCo/artcam Postp puts out, in the Z, the “random 480” appears on all of them. I run at fairly high speeds usually, 60-120 in/min. In an edited gcode test this morning, without the “Random 480” the Z speeds crawl, with-normal, for me, speeds all good.
Checked the “start gcode” setting. It is off. I have ran it “on” with no ill effects when I had stalling issues (on older TFT firmware), it helped that somewhat.
Much like last year about is time, updating the TFT went badly here for some reason that You, Jeff and I never worked out. You actually sent me the pre-pre release TFT firmware, via dropbox, never did work and I gave up and went back to known good.
More than likely it is something unique to the TFT screens I have, both bought within a couple of months from V1, so no worries.
At some point I am considering a newer board and TFT for the 2 MPCNC’s.
One last question, Have you looked at the BTT SD cloud wifi? biqu sku:ZZB000420
SD card slot size, with TF slot, looks like an interesting way to cut down the wires.
Although my issue isn’t resolved, like last year, I’m OK with it. If there is something weird I’ll get it, normal in my opinion.
All that setting does in inject “g28” when you run a program. Forcing all axis to home before it runs your gcode. It does nothing else.
The line should be correct to F480, not deleting it. All Lines should include a “F” command. I would look for a new post processor or update the one you are using those are flaws that should be corrected.
To give you an example, on teh first run without that line your Z speeds should be okay since the firmware loads safe speeds. But it you change your Z speed at any point it stays until you reboot. The post processor/gcode should be in full control of your machine at all times leaving floating feedrates will cause issues at some point. Either too fast or too slow.
This request removes your gcode and post processor from the equation. If the machine functions correctly we know what to focus on.
I am not, I want this to be as correct as possible. I sold you hardware if it is bad I want to replace it, but right now I do not think it is hardware at all. The only issue we have seen so far is a bad post processor. Our test crown can prove or eliminate that.
No currently I have been testing the esp-01 and it is fantastic.
Update on the experiments with SKR Pro 1.2, 515 firmware, a few days ago nightly, and newest CNC TFT firmware. On both MPCNC’s
Still haven’t found the “Zero X, etc” buttons. Ehh…no problem. Got some advice off forum. I just send G92.1 in the LCD. Works so far.
Got a ESP3D module from Ryan at V1. After looking at the current system, and sender that it has, I’d prefer CNCjs, but oh well. I am still running the gcode off USB 2.0 sticks in the TFT
Been messing with feeds,speeds, and acceleration. About have both of them tweaked to max, more testing needed, but repeatability is good.
Got off to a rough start this AM, not related to firmware. In flipping stepper wires to get everything going the right way, I goofed, and one was loose, made some dandy ovals, X@ being loose. Too bad, they were supposed to be circles, lmao. Eh, water under the bridge.
Edited config.ini for the TFT. Start gcode is now G92.1, and my knob color is back to the blue I prefer. Using the Unified Menu Material Theme is my preference.
You can swap the themes pretty easy, just swap the graphics folders when you flash the screen. I have them all still linked with the firmware. No need to even recompile.
