So I keep running into problems in ChiliPeppr when trying to do probing… I’ve lost several bits now and damaged a few boards, always it’s related to the controller thinking it’s at a different position than it really is because the location after or before the prob seem not to be in sync between ChiliPeppr and the TinyG.
This has happened 3 times now, I’ve started the bed auto leveling, and I have the bit zeroed out and sometimes it’s been sitting at 0,0,0, this time it was sitting at 0,0,1z, then it starts to level and when it begins checking the first point something goes wrong and it suddenly thinks zero is actually -15 or something like that, then drags the bit through the material as the it crashes and tries to move to the next point. I’ve probably successfully leveled 4 times, and then this is the third time it’s failed.
Here’s the log in this case:
Will probe 104 locations
Starting probe process
Getting your current Z Min homing settings so we can restore them later.
Going into mm and abs coord mode
Generating probe steps.
Generated 104 probe locations.
Starting probes
Moving to {x:15,y:6}
Zeroing out Z on 1st probe as baseline Z.
Moving to {x:15,y:13}
Working on probe for {x:15,y:13} Found lowest Z:-19.5
Moving to {x:15,y:20}
(Big red button)
Just tried again, now it’s all goofy… check out this log:
Starting probe process
Getting your current Z Min homing settings so we can restore them later.
Going into mm and abs coord mode
Generating probe steps.
Generated 104 probe locations.
Starting probes
Moving to {x:14,y:6}
Zeroing out Z on 1st probe as baseline Z.
Zeroing out Z on 1st probe as baseline Z.
Moving to {x:14,y:13}
Moving to {x:14,y:20}
Working on probe for {x:14,y:13} Found lowest Z:0.077
Working on probe for {x:14,y:20} Found lowest Z:0.077
Moving to {x:14,y:27}
Moving to {x:14,y:34}
It succeeded the first location, went up to like 5mm, then down 1 or 2 in the air at the second point, moved the third point and had to slow travel from like 4.5 down to the surface, made contact, moved to the 4th point, touched down in mid air, moved to the 5th point and started the slow travel down from 4.5… then i killed it. Looks like the log was duplicating itself? Is this because the first probe failed and I reset and tried again? Do I have to reload ChiliPeppr when something like that happens?
Notice how it goes to 1.5, then snaps to 5mm for some reason, so it has to slow search all the way from 5 to 0… then it reaches 0.
After it reaches 0 then snaps to -3.something… It did that on every point and I killed it again, this was after a complete fresh reset, reload of chrome and restart of SPJS
@Alden_Hart may have some ideas. I have heard reports about probing having some weirdness. The fact that you get jumping coordinates I believe shows a bug in the probing code in TinyG
It’s not clear to me where the problem may be, but please help understand the circumstances and I’ll take a closer look. Can you please tell me what spjs revision and tinyg build number you are using? Also what kind of machine you are running.
Question - are issuing a feedhold during the probing operation? It shouldn’t matter, but I am curious. Are other any other circumstances you can think of? I’ve run this many times and not seen the errors you are seeing.
Hi @Alden_Hart , I’m using 440.18 of the TinyG and V1.80 of SPJS. I’m running a modified Sanvn 3020T CNC, and my laptop is running Windows, it used to Run Windows 8.1 (and i had probing problems,) and currently it’s running Windows 10, and I always use Chrome.
I wasn’t issuing any feedholds during the cycles, and some of the cycles worked, I always started at 0, or just a tiny bit above 0, but the max distance was set to -0.5, and it was definately reaching the board in the examples above, except in the first example, every other point was in the air, but in the second example where I made the video, once it touched the board, the z-axis position went immediately negative by quite a bit (this seemed to happen after it stopped moving)
One thing I wasn’t sure on initially was when I did the first cycle that caused the bit to break into the board, I had used the “Test Probe” function which caused the bit to approach the board until it contacted it, then it stopped and it sounded like the motors stayed energized maybe? At that point I zeroed out the z-axis thinking that was normal, and then I started the prob. But it seems in many cases, when a probe cycle finishes the z-axis sometimes doesn’t know where it’s at, and in that case, when I hit “start” for the auto-leveling sequence it thought it was suddenly higher than it was (since it was at 0) and tried to then descend even more into the board.
Is there a command I can issue or something I can run so that I can issue a prob cycle, then check after that to see where the tinyg thinks it’s at? Not through ChiliPeppr, just from the command line.
I have a feeling that this happens after the board sends a status report to CP, and the only reason I see it during the autoleveling cycle is because the SR comes in as the board is moving to another location and begins sending SR’s again.
Jimmy, thanks for the details. Let me take a closer look at this Sunday when I get back to a machine I can test this on. I have run repeated bed leveling cycles before and not had issues, so I’ll be on the lookout for some way to repeat this.
OK if you need anything from me, just let me know, I’m around Sunday so I’d be happy to setup a hangout or goto meeting if you need more info or want to check out my board
Any luck with this? Just had the unfortunate experience of the z-positioning problem happening when I wasn’t even doing a probe cycle or anything. This is actually the second time this has happened, I had forgot it happened in a wood piece where it wasn’t a big deal… but I was working on aluminum this time.
I have a small area clear file with z0 for the whole file, I set G54 0 after I had manually positioned everything, then I raised z to 1mm, then I started the file and it immediately plunged down by at least 4 mm into my workpiece and triggered the thermal stop on my spindle because I couldn’t get to it fast enough. So, CP actually read correctly that it was at 1mm when this happened too… it wasn’t until I hit “go” though that +1 changed to +5 on its own.
Yesterday I outfitted my Shapeoko2 pen drawing head with a probe switch by looking for pressure on the pen. I ran 100+ probe autolevelers multiple times with no issues. Same setup as yours 440.18 / SPJS 1.80. I also captured the USB traffic on the wire using a logic analyzer to make sure there were no transmissions being dropped. (There were none dropped, but then again my tests were working fine.)
I’m sure you are familiar enough with the autoleveler settings to do the pre-run so it actually touches down reliably and lifts off reliably.
I’m suspecting that somehow a status report is not being processed correctly, or lost in transmission. What host computer are you running, and if you are on a virtual machine how much memory did you allocate to the VM? You might try dropping the size of the Gcode buffer to reduce memory requirements and see if this has any effect.
Also, in rare cases we’ve seen cheap USB hubs or cables causing problems, so we usually plug directly into the host computer with a high-quality USB cable to eliminate this variable.
Yeah I had been using the test probe to make sure it would work ok, I also use a voltmeter to check the connection from my touchplate to copper board wire is nice and secure too. I’m using a laptop to run everything, it’s running Windows 10 at the moment, but I had the same issues when i ran Windows 8.1, I’ve got a fairly decent quality cable that’s pretty short, only 1M going from the laptop to the TinyG, it’s a Lenovo Yoga 13, very decent ssd/ram/graphics card and proc in it…
Once the jobs start they seem to proceed ok, the problem I have is making sure they start, if it’s going to mess up it usually does it at the beginning of the cycle, I don’t think I’ve ever noticed it going weird in the middle of a job or a prob cycle.
One thing though you mentioned that I’m curious about, and I’ve seen this in the probe cycle too, it never lifts off for me when doing the test probe.
Sometimes when doing just a plain probe, it will hit 0, and back off just fine, but every once in a while it hits 0, and then just stops, and ChiliPeppr doesn’t beep, and the motor stays energized briefly then it de-engergizes and I have to manually move it up. When that happens it seems to mess up afterwards too.
When I do a “test probe” in the auto leveler, it never backs off, it just contacts at 0 then stops, is that what it’s supposed to do?
It’s almost like there’re values getting stored by either TinyG (or maybe cached somewhere in ChiliPeppr even?) that are getting reloaded, where those values were expected to be set at some other point… for example, maybe I have a config that sets my “offset when probe occurs” that’s getting loaded when it shouldn’t be or something? Are there such temp variables set, and is there a way to inspect their values before certain commands?
@jlauer , do you ever do anything with the machine coords when working with the touch plate or auto leveler? Is it possible those are somehow getting mixed in, I never change them and am always in G54, but when doing ? I notice they don’t match up with my coords and sometimes it seems like they’re off in the Z by the amount that my cycles get confused by… is it standard practice to zero everything out and maybe I’m not doing that the same way or something?