Deviation problem with configured axis
This is a deviation of almost 1% with F300. With higher speed it gets even worse. Of course I don't need this speed for milling but my table is splitted in 2 areas and when I use the rear area, I want to reach it fast.
These are the values for all 3 axis:
MAX_ACCELERATION = 15.0
STEPGEN_MAXACCEL = 18.75
Please Log in or Create an account to join the conversation.
kostas wrote:
I think there is no problem at all. When in G64 (the default), toolpath is never exactly what the g-code program dictates.
It should be in exactly the right place when it stops. There is no blending of stops.
Yes of course. Forgot to mention that.
Please Log in or Create an account to join the conversation.
I confess I am rather baffled by this.I moved the axis 50 times to 100 and back with F300 and it ended at 0. The caliper showed 0.01mm. I frequently measured the upper end and this was also always the same value: 99.14 to 99.15mm.
I guess that if you toggle between commanded position and actual position (# key) there is no indication that the machine "knows" that it isn't where it should be?
I have no expectation that this will have any effect, but if you halve those values, is the behaviour exactly the same?These are the values for all 3 axis:
MAX_ACCELERATION = 15.0
STEPGEN_MAXACCEL = 18.75
It could, just possibly, be step timing. (But that shouldn't be so predictable)
If you rapid to +200, feed to 0, rapid to +200, feed to 0, do you get a cumulative error?
(I am just asking questions in the hope of inspiration striking)
Please Log in or Create an account to join the conversation.
I moved the axis 50 times to 100 and back with F300 and it ended at 0. The caliper showed 0.01mm. I frequently measured the upper end and this was also always the same value: 99.14 to 99.15mm.
This is a deviation of almost 1% with F300. With higher speed it gets even worse. Of course I don't need this speed for milling but my table is splitted in 2 areas and when I use the rear area, I want to reach it fast.
At the end of the run does the DRO read 100 every time? If so it does sound like a mechanical issue. If the lead screw spec is 4mm then I would use that and not try and use a test indicator over a short distance to calculate the pitch. As others have pointed out the screw might have pitch to pitch errors and overall errors.
Are these ball screws or other? Typical specs for average ball screws are "accuracy for travel distance per turn is ±0.004" per foot" which is 0.1016mm so unless you have some high dollar ball screws you just chasing your tail trying to get better accuracy than the screw.
If you "map" the screws you can use a pitch map compensation file for each screw.
www.linuxcnc.org/docview/html/config_ini...b:%5BAXIS%5D-section
John
Please Log in or Create an account to join the conversation.
I have no expectation that this will have any effect, but if you halve those values, is the behaviour exactly the same?These are the values for all 3 axis:
MAX_ACCELERATION = 15.0
STEPGEN_MAXACCEL = 18.75
Wow, that seems to solve the problem: I set MAX_ACCELERATION down to 5.0 and now my results are not influencedby the driven speed anymore. I will run some more tests tonight and let you know if the problem is really solved.
It could, just possibly, be step timing. (But that shouldn't be so predictable)
I just wrote a mail to the manufacturer of my controller, a Benezan Triple Beast. I found the values for step time, direction setup and direction hold in the manual but no value for step space. Since all other values are 2µsec, I just entered 2µsec for step space as well and the motors ran smooth. However, I hope he will reply to me soon and give me the correct value.
At the end of the run does the DRO read 100 every time? If so it does sound like a mechanical issue. If the lead screw spec is 4mm then I would use that and not try and use a test indicator over a short distance to calculate the pitch. As others have pointed out the screw might have pitch to pitch errors and overall errors.
Are these ball screws or other? Typical specs for average ball screws are "accuracy for travel distance per turn is ±0.004" per foot" which is 0.1016mm so unless you have some high dollar ball screws you just chasing your tail trying to get better accuracy than the screw.
As I wrote earlier here, these are high precision trapezoid screws with a maximum tolerance of 0.05mm on 300mm distance. This is even much better than the 0.15mm tolerance on 300m, according to DIN 103. After I've got this information, I set the screw pitch back to 4.0mm because obviously my caliper ist not as precise as the screws are.
If I had pitch to pitch errors, the measured values would vary with the distances but not with the speed. I can measure any distance anywhere on the axis, there are no deviations at all if the machine runs with G61.
Let's hope that MAX_ACCELERATION was the problem.
Please Log in or Create an account to join the conversation.
Wow, that seems to solve the problem: I set MAX_ACCELERATION down to 5.0 and now my results are not influencedby the driven speed anymore. I will run some more tests tonight and let you know if the problem is really solved.
Excellent. What that means is that you were missing steps during the accel phase, but in a freakily consistent way. That consistency says good things about the rest of the system.
I just wrote a mail to the manufacturer of my controller, a Benezan Triple Beast. I found the values for step time, direction setup and direction hold in the manual but no value for step space.
On a parport based system don't worry too much about the step space, on a typical EMC2 system it will be "whatever time is left out of the pulse frequency after the step time"
Don't push the direction setup and direction hold numbers too tight, you are always stopped when you swap those over anyway. However there is a CPU load advantage on keeping the step time as short as gives consistent and reliable operation.
None of the above applies to external step generators like Pico, Mesa, Pluto etc.
Please Log in or Create an account to join the conversation.
As I wrote earlier here, these are high precision trapezoid screws with a maximum tolerance of 0.05mm on 300mm distance. This is even much better than the 0.15mm tolerance on 300m, according to DIN 103. After I've got this information, I set the screw pitch back to 4.0mm because obviously my caliper ist not as precise as the screws are.
Sorry, I missed that bit of info about the precision of your ball screws.
John
Please Log in or Create an account to join the conversation.
Given that the problem DOES appear to be missed steps (through accel figures being too high, which was one of the causes I speculated ), can you settle the G61 issue referred to in the initial posts.
I thought G61 must be able to control velocity and acceleration, to be able to come to absolute path co-ordinate.
This to my mind was why there was no undershoot when G61 was used.
Is that right or is there some other reason why G61 worked?
regards
Please Log in or Create an account to join the conversation.
Is that right or is there some other reason why G61 worked?
I can't think of a better guess, so perhaps that is it.
I had actually forgotten that G61 worked.
Please Log in or Create an account to join the conversation.