Reply with QuoteIs it always one axis? Always consistent (both in occurrence and amount)? Happens both in MDI and from a file?
Loss of Steps
Anyone else seen this issue? I can set a reference point and using the jog wheel, move the table around like crazy and have it come back to the reference point with a reading of 0.003mm. Running a program where code is having the mill move in one axis only, it can be out as much as 0.15 when measuring the reference point!.
Stats - PCNC1100 S3
Computer - Tormach supplied running PPv2.02
Things i have checked - Gibbs, Ballscrews, Backlash
Any help would be much appreciated!
Cheers
Shane
Similar Threads:
Re: Loss of Steps
Is it always one axis? Always consistent (both in occurrence and amount)? Happens both in MDI and from a file?
Re: Loss of Steps
Thanks for replying
Its on all the axis with "Z" showing the minimal amount of loss steps. Sometimes its negative an other times positive with inconsistent readouts 0.089 to -0.149
MDI line and jog wheel is fine. It only shows when running code.
Re: Loss of Steps
I'd try rolling back PathPilot to a previous version.
Also swap the wiring from the Z driver with the X or Y.
Just tried this with no luck. Tested line signals with a scope and it looks good.Originally Posted by footpetaljones
After everything that I have done I'm wondering if it's software as in PP. What would be really helpful and much appreciated if someone could run the same test.
Run code to have the x axis move back and forth around 10 times and see what the origin comes back as.
Re: Loss of Steps
Is anyone able to run the above test? Be really cool if i can verify that PathPilot not causing the issue.
1 -Set a origin on a block or vice. 2 -Jog the table around erratically and come back to you origin and see if there is any offset (I tried it on "X" and it was 0.005mm max)
3 - Using conventional milling, create a program that only moves back and forth in the "X" axis around 10 times and measure of "X" again once finished ( I was getting 0.15mm!!)
The amount while running the code can vary from negative loss to positive loss.
Once again would really appreciate it. (Im working with Tormach now but for some reason they are not willing to run the test???)
Cheers
Shane
Re: Loss of Steps
No test is required because Tormach and most of their mill and lathe users already know that those machines do not miss steps. If you purchase a new car and the engine dies above 13 MPH should the car manufacturer be forced to test drive some of their new cars on the same road where your car dies?
Your problem could be due to flaky interconnect, a flaky PC, an electrically noisy environment, etc. And what do you mean by "Tested line signals with a scope and it looks good."? Note that I am a former oscilloscope designer so don't worry about getting too technical.
Re: Loss of Steps
Im trying to prove the software side of things here. Pathpilot is reguly being updated for bugs. Take for instance the last update where the mill was timing out on a touch all tool calibration. Also i found a bug where if you had the soft keyboard up and set gcode over the network it would freeze up the program so im not sure what angle you are coming at?
We check the lines coming of the Mesa card looking for noise right up to the controllers and it was fine so im thinking its not hardware thats the issue.
Jog wheel around the table is fine for accuracy its only when you use code im seeing the issue.
video below showing the issue:
Video 1 showing PP create code test and the result:
https://photos.app.goo.gl/ioSnSxGE5E4U69pf8
Video 2 stimulating the gcode with the jog wheel:
https://photos.app.goo.gl/q34BKdTUVh2iPHvD7
Last edited by Shane658; 07-27-2018 at 06:17 AM.
Re: Loss of Steps
If you put a G61 in the code does it make any difference
Re: Loss of Steps
If there were a software issue with lost steps and normal gcode files (and therefore common to most Tormach users), I would expect a
large number of same Tormach users to have the torches and pitchforks out...
Since this does not appear to be happening, it does suggest that there is a specific issue with your machine, though with odd symptoms.
Re: Loss of Steps
Update
I have taken more video showing how strange this situation really is:
1 - I have referenced the block on G54 and zeroed off. Then i switch to G55 and reference at the limit switches and Zero off.
https://photos.app.goo.gl/bb27V7UoJvC59B3Q7
2 - Run the X Axis test which again is just going back and forth on the X axis only, re-probe and get a reading of 0.120mm out on the X
https://photos.app.goo.gl/vBXweSSkLfNydrsv5
3- Check G55 to see after referencing that the DRO is at "0" which it is. Come back to G54 and the part is out by 0.120mm
https://photos.app.goo.gl/hw1QhQTTnQabTxY67
So with the above test, it looks as though the origin for G54 has moved but yet the table hasnt as its able to read zero in G55 at the kill switch locations. How does it keep the kill switch locations precise yet goes out on the G54 origin?
Re: Loss of Steps
Hi,
that is strange indeed. I'd garee with you that if G55 still zeros correctly, then it's not the machine losing stepd, rather something's going on with G54.
Are you by any chance using cutter compensation or backlash compensation? I don't use either and I don't use PathPilot anyway, but it does occur to me that those things could be handled differently when running a program as opposed to jogging around, so that would be my next check. Beyond that I'm afraid I'm as baffled as you.
David
Re: Loss of Steps
I would be suspect of the indicator you are using to check it with.
Maybe make the moves many more times and see if the error gets progressively worse.
Even a renishaw probe will show a tenth or so discreppancy on different moves, so maybe it could be the accuracy of the probe?? just a thought..........
I would check the couplers on the axis in question to make sure it isnt slipping, mark it and see if it moves in subsequent moves.
I see that you are using the Haimer in the later videos, that should be very accurate, the first one I would be suspect of.
Last edited by popspipes; 07-30-2018 at 10:46 AM.
mike sr
Re: Loss of Steps
Haimer probes can unscrew just a little which will drive you nuts with random errors until you figure it out, but that shouldn't differ from code to jog I would think.
Re: Loss of Steps
Thanks for all your help!
Finally got to the bottom of the issue. Long story short, it was the spindle. The collet housing is not tapered correctly and Tormach are replacing the spindle.
So what would happen is setting the origin with the probe and then cutting air would have the probe put back into the spindle on a new offset due to the collet spinning to a new offset point. I marked the spindle so the probe could be loaded in the same location each time and sure enough i got accurate readings. Splin the spindle 180 and it was out buy 0.16mm.
I only found this due to using an edge finder and it would find the origin with accuracy no problem as you have to have it spinning to get a reading. Any offset on the collet is being compensated with the way the edge finder works. Also we know its the spindle as outside spins concentric and is in spec.
So after all that, it was relief to finally get to the bottom off the issue. Easy to get mislead and head down the wrong path.
Re: Loss of Steps
glad you got it worked out.
Makes me curious about mine as I've never check the spindle with the haimer turned. I to have my spindle marked in two locations so it's always inserted in the same way.
