[whagkangmakulet]

Anyone experience offset value height change by itself on Pathpilot? It sounds stupid but for some reason the offset value of my tool #1 which is where my Haimer 3d height value increased by 3+" which plunge my superfly and damage R8 adapter collet which will cost me a lot of $$ that I barely have and concern with this Pathpilot. I normally check my offset value on tool #1 if I see the dial is not lined up with the red needle or broke a tip. I never experience this on Mach3, perhaps I might have done something that wish I knew how. Any ideas that I might have caused this?

[wtopace]

I have never seen anything like the issue you are referring to, but I do check my offsets when loading new tools or running a new program for the first time.

I keep a 6" machinists rule on my tooling cart next to the mill and "g0 z6" after setting the tool number, then make sure the machinist rule just slips under the tool. This is a really quick sanity check for me and it allows me to run through my entire tool list quickly, usually in under a minute. Plus, it can prevent lost $$$ in crashed tooling =)

[compunerdy]

I found it easy to accidently change offsets when working in the offset table. But other than that the only issue I have had is that my X axis limit switches do not seem to set the same offset each time.

[popspipes]

I had an issue with the Z axis not going to zero when it was reset or zeroed, it would reset to the tool length in the tool window for some reason not zero as it should. I found that by hitting stop and reset and the G43 button has cured the problem. I just hit stop and reset G43 before doing anything now if the machine has been unused for awhile, it hasnt done this since.

The only anomaly I have had lately is running the wireless adapter thru an extension cable, this wont let me load files thru my thumb drive on another extended cable. The fix for this is not to use the wireless adapter for the time being.

I have been leaving the computer on continuously without ill effect as well. I dont think this is a recommended procedure but it has not shut down a usb port, even when tigging with hf start.

[Beezle]

I had an odd offset thing happen today after updating to 1.7.2.

After updating, I referenced the 3 axis, loaded a SprutCAM generated program I have been using for weeks. Since PP 1.5. I then used a Haimer to locate a blank in the vise. 0,0 being the top center of the block.

I think checked one tool for height and decided update its offset in the offset table. Not a tool I was using.

I then used the MDI to move the spindle to 0, 0. I always double check. But suddenly, Y0 was at the near edge of the blank, not the center. I am certain that I centered that DRO and the value was correct. Half the width of that axis. Then checked Z just to make sure and it was fine.

Ran the program twice before I realized that the X axis was offset by about .02 or so. When I centered that axis, the same thing, the length and half lengths were correct in the DRO as I found those edges. Wish I had double checked that too.

Since then, I have of course re-located the work and things are fine. But though we all of course make mistakes, my set up ritual checks itself well enough that I think something actually went wrong. What, I do not know.

[quarky42]

I ran my first part in PathPilot tonight. It involved two separate gcode files. A roughing file. A tool change. Then a finishing file. After the finishing gcode completed, I jogged the x y and z a little bit and changed to a third tool that I was going to try the conversational wizard with. I ordered it to go to z-0.095 and before I knew it, the mill head crashed into the aluminum soft jaws I had just been milling. It went way further down than -0.095 and my other movement commands before this had been working great. I looked and my X and Y values were still normal relative to their origin points. The z value was way out of whack with its origin point. This really upset me and I can't swear that I didn't do anything wrong, but I really didn't do anything after running the second gcode operation. A little jogging of the shuttle wheel shouldn't have done anything like that.

Edit: This was in 1.8.2.

[tmarks11]

A couple of questions:
1. Do you have an ATC?
2. If you don't have an ATC, did you forget to manually update the tool number after the change to the third tool?
3. Are you sure the tool height offset for that third tool was correct?

[quarky42]

A couple of questions:
1. Do you have an ATC?
2. If you don't have an ATC, did you forget to manually update the tool number after the change to the third tool?
3. Are you sure the tool height offset for that third tool was correct?

No ATC. No, the tool # was correct. Yes the tool height offset wad correct too.

I rezeroed my z origin point and ran two paths with that tool. I ran those same two cutting paths a second time. All without further problems.

When it went crazy it plunged wayyyyy too far down. I was using a rapid z command instead of a feed rate one, which I realized can be dangerous, but in my defense I was really close to where I commanded it to be. I expected it to just move a little bit. ...not shoot down inches. (Really, the travel I was expecting was less than a quarter inch. I was not expecting he z work origin to have suddenly shifted many inches.)

Before the crash, I had run a roughing program and a separate finishing program. After making that pair of vise jaws where I had the crash I later made a second pair using the same code and this time z didn't lose its work origin. (When it lost it during the first pair, I saw after the fact that z dtg was -10 something and x and y dtg were 0. When I rezeroed z work origin the z dtg went back to 0. How it changed / lost the info is beyond me and it did not happen during the second pair of vise jaws.

Thank you for trying to work through it and look for reasons. I really think it is a bug at this point because I really didn't do anything except jog and I definitely jogged during the second pair too, twice because I have to cut the dovetail on one jaw at a time. If I made a mistake, I'd be glad to know it because I could avoid it next time.

[phoneman]

I had a problem with the first update Tormach did for PP. After the update my probing was goofy. When I figured it out the update had zeroed out the tool diameter of tool 99 my probe so every thing was off by half the probe diameter. Once I corrected the tool table every thing is fine.

Dave

[tmarks11]

I really think it is a bug at this point because I really didn't do anything except jog and I definitely jogged during the second pair too, twice because I have to cut the dovetail on one jaw at a time. If I made a mistake, I'd be glad to know it because I could avoid it next time.

You were using MDI for the command, something like G00 Z-0.095?

Please submit it to Tormach's bug tracker.

http://www.tormach.com/pathpilot_tracking.html

Not related to your problem, but I got caught by the V1.4 bug that had run-away when jogging. Crashed a 1/2" endmill into the side of a workpiece. I was about 1/4" from the part, in continuous mode, just tapped the arrow key on the keyboard to jog it over slightly... zoom! bam! Looked at the bug fixes on the V1.5 release, and there it was. Cursed myself for not updating; scratch one endmill Glad it hit the workpiece instead of the vise.

It is very possibly that you have found something similar... the trick is to convey the exact sequence of actions (including Tool Table entries) so Tormach can try to replicate it.

Fix for #827 Mill - Keyboard jogging: Short tap of jogging key after MDI move or program run results in runaway jog

[Uman]

If using electronic height gauge, a second tool offset value may have been inadvertently entered when tool #1 ,Haimer, was selected/active in PP.
Tool #1 Haimer may have been used to set Z axis, while another tool was selected/active in PP.

Look at your tools and determine which one matches the error value of tool #1 and retrace.

edit; thought of another possibility:
If using the electronic height gauge, I experienced an error input when the signal connector mate was loose at the electronic gauge head during initial zero or data input.