Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: calico on January 04, 2011, 12:00:50 AM
-
I have this problem when cutting sphere using radial cut import from Mastercam toolpath.
no matter how slow the feedrate I choose, it always create loose steps.
is this a compatibility issue or my router setting is not right ?
I use very slow feedrate but still dosn;t solve the loosing steps problem.
anyone experience this ?
help...
-
Is your Z axis a lot slower than X and Y?
Try running in Exact Stop mode (G61) and see if it still happens.
Hood
-
Z might be slower, it's because the ballscrew Z lead is like 1 inch, but X and Y is about 1/8 inch.
now how to set exact stop mode on x y and z ?
I'll try tonight.
I try to set the Step pulse and Dir pulse to 15us, I tought it solved, but it not.
-
I think I remember Ray Livingstone having an issue with helical paths when he was using the knee on his mill for the Z axis. The knee was a lot slower than the X and Y and that seems to be the problem if I am remembering correctly. I think he was fine if he worked in Exact Stop for that part of the code but I may be recalling incorrectly.
To set to Exact Stop just insert a G61 in the code just before the problem part of the code and then a G64 after the problem code to put it back to constant velocity if required.
Sherline mode may help if you were seeing improvements with the wider pulse but Sherline can only work at 25KHz kernel
Hood
-
Just reading again and you said radial paths, is that just X and Y moving and Z stationary until Z moves down with X and Y stationary? If yes then what I described above is not likely to be your problem but maybe the sherline will help.
Hood
-
here is the picture of what I'm cutting.
it's radial with Z depth.
I use to use G64/constant stop before, it give me the same result, so I try this smooth const. Vel.
now I realize, this might help you to solve problem.
when the mach3 read gcode lines, it stop for split second before reading to the next line, it's not smooth reading, that's the moment "loosing step" ... I think.
now how the mach reads "stop" momentary ? does my computer too slow ? or need bigger buffer ? CPU ?
-
With such a large lead on the Z axis screw, it may be an acceleration issue on Z. Try lowering the acceleration on the Z axis.
Mike
-
From your descruipyion of the stop at the end of each line of code that sounds like you are using Exact Stop (G61) already.
Do you have backlash comp enabled, if you do switch it off and see if the problem is solved.
Hood
-
I did try lowering the Z axis acceleration, still the same problem
is this because of the Z ? something got to do with Z that cause this loose steps ?
I use Backlash Comp enable already.
now I'm thinking that my PC is not catching up reading the Mastercam gcode lines.
-
Please disable the backlash and see if that cures your problem, if it does then you may need to tune the backlash settings better when you re-enable them.
Hood
-
just tried the backlash off, still the same result.
-
Out of interest, what are your acceleration settings. If it losing steps at the end, or start, of a line of code when in exact stop, this could still indicate acceleration problems. You have a huge difference in leads between your X and Y axes and your Z axis. I would expect you to have to have a large difference in your acceleration setting between these also. With a 1" lead on Z, it takes a very large amount of energy to get it moving and it could just be that it is too much.
Mike
-
In addition to Mikes question,
Which axis is losing the steps?
What type of drives do you have?
What type/size of machine?
What size motors?
Hood
-
X an Y axises is loosing steps.
I use step motor drive from gecko
what type of machine ? I built my self... it's a router with about 1 meter square travel
motor size is ... the diameter of the motor is about 4 Inch. forgot the nema size.
-
Mike,
I think what you said is make sense, I will check the acceleration between those 3 axis, and try the result.
here is the acceleration setting I had
XY steps per 157.48, Vel 1999.8, Accel 200
Z Steps per 100, Vel 1999.8, Accel 100
Out of interest, what are your acceleration settings. If it losing steps at the end, or start, of a line of code when in exact stop, this could still indicate acceleration problems. You have a huge difference in leads between your X and Y axes and your Z axis. I would expect you to have to have a large difference in your acceleration setting between these also. With a 1" lead on Z, it takes a very large amount of energy to get it moving and it could just be that it is too much.
Mike
-
Mmmm, I would expect it would be the Z axis losing steps if it were acceleration issues. However, it still could be. Could your X and Y axes be binding anywhere or stiff to operate? This too could cause missing steps.
How long has this been happening? Is it just on this job or has it always lost steps?
Mike
-
if I do the radial cut with Z depth, it's 90% loosing.
if I do only circle/pocket cut it's like 30% loosing.
but never loose on Z !.
X Y binding or stiff ? I have no idea how to check, but I never bind nor stiff X and Y, I don;t know how to.
very notice loosing when cutting radial on Sphere object, reading the lines sometime stop for split second, it's not smooth reading the gcode lines.
I don't think I have backlash on XY or Z.
the result when cutting sphere is not always the same spot (loosing step)
it's never on Z, I don;t think Z ever loose step, as far as I know.
this been happening since the beginning, but I never notice I though my feed rate is too fast.
now I know is not the feedrate.
I rarely cut Sphere, but since I found this problem I got to solve this by cutting sphere for testing.
-
I presume, from your steps per and previous info on screw leads, that you have some gearing or belt reduction on your axes? Can you let us know? Also, what type of screws do you have ballscrews, acme, etc.?
You might want to try lowering the acceleration way down on all axes and see what happens. Mach will take care of the coordination.
I've just read your latest and it is well worth trying the lower acceleration.
Mike
-
mike,
I will do test tomorrow the acelration.
I use Ballscrew with 5 mm lead on X and Y.
I use ballscrew on Z with I think about 1 Inch lead.
I use step motor with NO gear ratio nor belt reduction, it's a direct drive from motor to ballscrew.
-
mike,
I just tried... I can not wait till tomorrow.
the result is still the same.
I decrease the acceleration to 25% on each axis. so it's 50 on XY and 25 on Z.
no good
-
Do you lose steps when just moving one axis?
If not then if you have a volt meter command a move on 2 axis and see if your power supply is managing to keep a steady volytage in to your drives.
Then same with a 3 axis move.
What are the specs of your computer and also can you attach your xml just in case there is a config issue.
Hood
-
ok, if one axis move it's steady, I will test the voltage tomorrow, that will takes time to open the controller.
I will attach the xml also
thanks
-
I use step motor drive from gecko
ergo full, half, 5 or 10 microstepping depending on which drive.
I use Ballscrew with 5 mm lead on X and Y.
...
I use step motor with NO gear ratio nor belt reduction, it's a direct drive from motor to ballscrew.
XY steps per 157.48...
Am I missing something here?
-
Yes, something is definitely odd in the motor setup. Also, if the Z axis is really 1" lead (25.4mm) and the X and Y axis are 5mm lead, all three are direct drive then the microstepping must be different for for the Z axis.
We need more and accurate information.
Mike
PS Is this a metric or imperial machine? I am assuming metric.
-
Hopefully the xml will shed some light on things.
Hood
-
I can not see my attachment file I just reply ?
that's funny.
here it's
-
You may have to rename your xml before the forum will accept it as it only allows a file name to be used once.
Hood
-
I just modify the previous reply with attachment
-
What is your look ahead setting?
How fast is your computer?
(;-) tp
-
I'm sorry, how to check "look ahead setting" ?
it's Pentium 4 with 2Gb memory
-
Its set to 20 according to your xml, you may want to increase that.
What rev of Mach are you using?
Hood
-
I just upgrade the mach to the latest 1 month ago.
increase to 50 will be ok ?
-
Terry would likely be able to advise better but try at 200 and see.
Hood
-
I will do that
-
You do have strange values for steps per unit with the hardware you said you have (Geckos, 5mm pitch and no gearing) If you command a move of 10mm via MDI line does it move 10mm?
Hood
-
strange, I just check to Genereal config, it's already 200 for look ahead.
yes it move the correct distance up to 0.3 mm accuracy if I command, maybe less.
I'm not really sure it's 5mm.
-
btw I use 100Khz kernel .. is this too fast for my PC ?
I was using much lower before but give me the same result
-
Obviously the xml you attached is not the same one you are using as look ahead is 20 and kernel is 25KHz in it.
Setting the Kernel to 100KHz is not a good thing to do if you dont need it and from your steps per unit you could run no problem at 25KHz so probably best you try that.
Also if you can attach the correct xml it may help if there are config issues.
Hood
-
jere is the correct one,
sorry for giving you the wrong xml
-
XML looks ok from first glance with the exception of the high kernel, would set that to 25KHz and see if it helps.
For future reference you must have 0.5inch pitch screws on the X and Y and 20mm pitch on Z.
Hood
-
Hood,
thank you very much for your help and support, I appriciate that.
I will do the kernel to 25 like I used to be.
Cal
-
I'd just add that you have your Y and Z step signals set active high. This is wrong for geckodrives which all step on the falling edge. There is also no need to set pulse widths to 5. The default of 0 is correct for geckos. (actually these values are ADDITIONS to the default pulse widths which are around 1 to 2 us so you actually have pulse widths of around 6 to 7 us. This in conjunction with your 100KHz kernel (10us period) is not doing the geckos any favours.
Ian
-
Ian,
noted.
thanks, will check an try that
Cal
-
ok guys,
bad news. I have the problem show up again.
losing steps.... not on Z. never lose on Z.
I'm stuck, I have no problem cutting straight pocket or anything that straight on X or Y.
but the problem sometime appear on radial cutting, specially with Z depth Radial cutting.
never lose on the exact spot !
help ...
-
Did you check the voltage is steady on your power supply when moving all axis together?
Hood
-
omg forgot to check that, that will takes time to open the controller casing.
-
I have not got time to open the controller box yet to check the voltage.
what happened if the voltage drop ?
what's the tolerance ?
just to make sure, to check is the voltage/PSU that goes to the Gecko controller right ?
-
Ideally you dont want to see the voltage dip at all but maybe a few volts would be fine if its dipping by quite a bit then that could well be your problem.
Yes the DC output of the power supply is what you want to measure.
Hood
-
Hood,
I just check the voltage.
I use 65 DC Volt on my Gecko drive.
and it very stable when the axis move only drp to 64.7 or around that much on X Y and Z drives.
-
Obviously that is ok, so dont know what else to suggest I am afraid.
Hood
-
oh man ...
Hood thank you anyway for trying to help me.
.....
-
Something which you can try is to put a dwell every so often in the code.
Maybe every 100 lines just add a G4 P5 ( the 5 in P will cause the axis to stop for 5 seconds).
The intent would be to find some code or spot which is causing the burp when machining. Radom stuff can be hard to track down and
this just may narrow it down to a combination of code which can be repeated and thus give you a hint on were or what to look for.
It would be nice if you had a digital display such that you could compare that display to what Mach DRO is showing.
That would show if it is somewhat progressive leading up to a something.
It possible it would be interesting to try swapping the axis around ie; Since it skips on only the x or Y ....let the Z move in place of the X & Y and see what happens.
Another way ,which is may not be an option, would be to run the code on a different machine using the same controller and see if there is any problem.
You are using backlash compensation....correct?
RICH
-
OK let's step back and start again.
IS this a laptop computer?
HOW are you determining that the XY are loosing steps?
(;-) TP
-
BR549,
Normaly you know if the steppers have skipped as your can hear it and know you have lost position or steps.
Sometimes the axis will go off on it's owne, but, what i have found here is that when doing small numerous moves that you can loose steps and not hear it
or know about it ( which really supprised me). Mill here never missed a beat in years until i tried doing 3D contouring with it. I think i have figured out my
mills problem but will not muddy up this thread with it. There have been about 3 posts from folks with similar problems in the last six months when they are
contouring something.
RICH
-
OK let's step back and start again.
IS this a laptop computer?
HOW are you determining that the XY are loosing steps?
(;-) TP
I'm using PC with pentium 4, 2Gb RAM.
if you check my prev. there is a photo of how I find out loosing step. it's a radial cutting with Z depth.
it's a radial cuttingl for half sphere shape.
Something which you can try is to put a dwell every so often in the code.
Maybe every 100 lines just add a G4 P5 ( the 5 in P will cause the axis to stop for 5 seconds).
The intent would be to find some code or spot which is causing the burp when machining. Radom stuff can be hard to track down and
this just may narrow it down to a combination of code which can be repeated and thus give you a hint on were or what to look for.
It would be nice if you had a digital display such that you could compare that display to what Mach DRO is showing.
That would show if it is somewhat progressive leading up to a something.
It possible it would be interesting to try swapping the axis around ie; Since it skips on only the x or Y ....let the Z move in place of the X & Y and see what happens.
Another way ,which is may not be an option, would be to run the code on a different machine using the same controller and see if there is any problem.
You are using backlash compensation....correct?
RICH
adding G4 and P5 ... that's a lotta adding on my 30.000 lines.
but for sure it's loosing when cutting radial (XY) with Z depth for "half sphere" cut.
Yes it would be nice to have a digital display. :)
I don't think a good idea swapping the x to z axis, since it's different lead on my ballscrew, course I can change that...
but I just don;t want to.
I would like to try to do it on the other machine, but I don't have anyone I know who has this kind of machine.
I know commecrially and I'm sure they will laugh at me.
no I don't use backlash compt.
do you guys know how long I built this CNC Router with my own hand ?
14 months, I built from scratch, welding, soldering, etc. done on weekends.
it's about 1 meter square travel on XY and about 40 Cm Z travel.
thank you
-
Rich,
you said there are 3 people having the same counturing problem.
did they solve the problem ? or they just like me now ???... ?
I wonder when Mach4 upgrade release ?
-
The problems "seem" similar from my recollection.....and don't remember some specific resolution of the problem.
RICH
-
I'm with Terry here when he says:
HOW are you determining that the XY are loosing steps?
I've just read the whole thread again and there is abosultely nothing here that SHOWS us that it's X/Y that is losing steps. You MAY be right, but the way I read this it looks more likely to me that it's Z.
BTW - did you change the step pulses for Y and Z to active low?
Ian
-
I'm with Terry here when he says:
HOW are you determining that the XY are loosing steps?
I've just read the whole thread again and there is abosultely nothing here that SHOWS us that it's X/Y that is losing steps. You MAY be right, but the way I read this it looks more likely to me that it's Z.
BTW - did you change the step pulses for Y and Z to active low?
Ian
when I see the result of cutting sphere, the Z depth cut is exactly in the right measurement.
yes I did change Y and Z to active low.
-
when I see the result of cutting sphere, the Z depth cut is exactly in the right measurement.
I'm not sure what you mean by this. If when you've finished you have a "ding" in the surface of the sphere, how do you know whether it was X/Y or Z?
i.e. if you start at the pole and XY takes you radially to the equator as Z descends. THEN if X/Y miss steps then "correct" Z movement will cause the ding. BUT if X/Y move normally and Z erroneously drops you'll get that same ding.
I'd suggest you arrange a datum somewhere off model for XY and Z, do your job and return to datum. Try this both for real and in air with spindle off.
Ian
-
Ian,
the reason I found out X or Y ... not Z is:
I make a drill/mark on the table 0,0 (X,Y)
and I cut/mark the 0 depth.
after I cut "half sphere", I press home (0,0,0) and it shifted about 3mm from the mark I created before.
then I check the Z cut I created before, it is still at the same height.
I will take a photo tomorrow the shifted cut.
-
How about putting a dwell every 6000 lines of code or maybe back to your reference. If you are doing a rough, finish and maybe waterline then one after each of those. Have the machine return to your 0,0,0 ref after each and to see what's happening.
May narrow it down some.
RICH
-
oK Next question when you did a voltage check on the power supply were you running ALL three drives at the same time you took the voltage reading??
(;-) TP
-
oK Next question when you did a voltage check on the power supply were you running ALL three drives at the same time you took the voltage reading??
(;-) TP
Yes it was running 3 axis at the same time when I measure the voltage.
-
Ian,
here is the photos ... you can see the lost steps on 2 spots.
forget about the dimple, it's a hole on the next cut.
as you can see the Z /edge is very smooth/no loosing steps
-
Have you tried your datum check in air with spindle off as per my post #59?
-
yes I did, kind of to check the xy only.
what I did is make a 0,0 mark before I cut.
after finish cutting sphere, it was offset like 0.5 mm.
but the result.. looks fine to me.
I will try again tomorrow.
I'm sure that Z is not a problem.
btw, when I do cutting air, it's very rare to get lost step.
so I got to test cutting some wood.
-
yes I did, kind of to check the xy only.
what I did is make a 0,0 mark before I cut.
after finish cutting sphere, it was offset like 0.5 mm.
So would it be fair to say that cutting in air with spindle off results in less error? Do it a few times and see.
but the result.. looks fine to me.
Curious comment as you're still out by 0.5mm
btw, when I do cutting air, it's very rare to get lost step.
so I got to test cutting some wood.
??? why do you think I asked you to cut air?
-
yes is would be fair cutting air is less error than real cutting.
I just did some testing.
this time I checked from the reference 0,0 that only X is shifted about 1mm.
the result like these photos.
actually I just narrow down the issue into X .
and I hope Y is not the issue.
I will do some testing again. will post later.
-
this result is much better than before.
is it possible that my X backlash create this problem ?
I tested before the X backlash and the result was ok.
I Will test with real cut for X backlash this time.
-
After finding the backlash on X about 0.5 mm, actually not a backlash, it was the X spindle mount that was not tight enough.
so I fixed that and running the real cut.
the result ... still the same, but this time when I go back to Home/reference, X0,Y0 it it Correct 0,0. no shift at all.
that was 3 time testing with checking to reference 0,0. no shift at all.
Now I see a pattern like X pattern of problem from top view, I hope you guys have an idea what's wrong or something worth to check.
what I hear when it cut radial on Diagonal cut it sounds like loosing step/louder.
is this not right ??
I use the motor accelerator at the lowest around 8 on XYZ.
I don't know where to ask for help.
Help ???
-
Calico,
Can you post the Gcode file your using?
There appears to be some repeatability from what i see in the pic's .The four gouge points are somewhat in the same place.
There are differences in the cutting between the pictures. If the gouge points are towards the end of the code that would indicate running time is a factor.
RICH
-
here is the Gcode.
thank you
-
Calico,
Based on the pictures "seems " like it's gouging somewhere in the first 2000 to 4000 lines of code.
I assume you have a viewer, so find find where the rough is commanding the moves to that level.
The pic attached shows the rough progression to about 2000 lines.
Deleting all the code past that level would allow you to run a much shorter program to analyze the problem.
Hopefully it's repeatable
RICH
-
Rich,
Thankyou for yor time helping me on this issue.
I have done using only smooth cut, no rough code, just cutting air, the result is fine.
If I cut the real material that will break my bit.
Smooth gcode cut air have a good result but i had tested good with rough and finishing gcode once.
If the rough cut is the cause of this issue I can use any othrr rough toolpath.
But I'm very curious about this issue, why the rough cut cause this? Assume if is is the problem.
Cal
-
If i find that line cause the issue then what should i do ?
-
Calico,
You are loosing position at a number of spots along the way. So it is not only the roughing. You can see it in the pictures.
I wanted to find the worst / first ones that were causing the gouging and that seems to be in the roughing.
Seems that first gouging accurs, approx, after each 1/4 of code run at a particular depth level when roughing.
So it would be nice to just have that grouping of code to help find the problem, call it a test file.
Then you confirm that there is no error in the code for the Z depth cuts.
You then air cut with the test file and confirm you are not loosing position.
Have a look at the code and make note of approx how much material is being remove and do some manual straight cuts
in some scrap and see if you loose postion.
I think that over a period of time, you are heating up the stepper motor and causing the gouge in roughing.
You could reduce the rough cut depth so the motor is not working as hard.
In the finish passes it's also time related as every 1/3 to 1/4 of the code group you are out of position.
Maybe,generate code for a piece half the size and depth and see what happens.
Maybe someone can be more definitive......... ???
RICH
-
Rich,
I will try to reduce the rough depth first see what happened.
btw that issue never loose position, after those cutting I hit Home Z and it was the exact position xyz.
so I assume there was no loose step.
but I will reduce the depth, see what happened.
-
What your after is the code grouping where the big gouges occured.
From that code extract the pathing for a complete rough along one radial out from the center,add the next radial for a complete
rough to the bottom, make a loop out of it in a sub-program. This way you can just vary the number of loops and observe.
This way the file will be very small.
You can do the same for the finish pass.
What is causing it can be a number of things.
RICH
-
Ian,
here is the photos ... you can see the lost steps on 2 spots.
forget about the dimple, it's a hole on the next cut.
as you can see the Z /edge is very smooth/no loosing steps
that looks like you are missing the code to take out the material.or maybe it is jumping that section of code.
-
Calico,
Could simply be a mechanical issue.
You mentioned in #18 that you have direct motor to screw (couplings) I assume.
In #70 you mentioned a loose "spindle mount".
I'd go through and double check that ALL coupling connections are very secure and in good condition.
What you are describing is precisely what can happen as a result of slippage of any of these components.
It runs OK in air with no load on the cutter or axis, introducing the load might be enough to cause the slip.
Just something else to check.
Russ
-
Hi All,
I had a problem (missted steps / stalling) that always occured at the same point in a prog - and appeared to be a bug in the gcode / mach.... (YERRR RIGHT ;-)
After some time this was traced to the axis being juuuust a tiny bit stiff in a particular position in conjunction with that particular axis being a bit marginal in torque.
New motor and driver - problem solved.
ATB
Derek
-
Calico,
Could simply be a mechanical issue.
You mentioned in #18 that you have direct motor to screw (couplings) I assume.
In #70 you mentioned a loose "spindle mount".
I'd go through and double check that ALL coupling connections are very secure and in good condition.
What you are describing is precisely what can happen as a result of slippage of any of these components.
It runs OK in air with no load on the cutter or axis, introducing the load might be enough to cause the slip.
Just something else to check.
Russ
I did check those couplings and they are good, that's the first time I thought.
-
Hi All,
I had a problem (missted steps / stalling) that always occured at the same point in a prog - and appeared to be a bug in the gcode / mach.... (YERRR RIGHT ;-)
After some time this was traced to the axis being juuuust a tiny bit stiff in a particular position in conjunction with that particular axis being a bit marginal in torque.
New motor and driver - problem solved.
ATB
Derek
I change the X axis with new motor and driver already.
-
Calico,
Tend to agree with Derek and Russ in a general. Skipped steps is a rather loose term and "exact" reason can be very elusive. I think that you have mechanical / electrical mechanical problems that are creating the skip.
Certainly can be wrong! Once you have a program that allows for repeating the problem then you have a means to narrow it down through disciplined observation and testing.
Here is a true practical example. Like you ,I have a problem with a mill that will not do 3D fine cutting without fault.
I machined the same piece using my engraving machine and same code. No problem at all ( three tries / 20 hours of machining / and the engraving machine uses 253000 steps inch...but no problems ).
The mill was found to have an axis bearing problem such that normaly it would not show up, but after measuring the torque required to turn the screw, after some "manual similation" of code moves , i found it requires an additional 70 to 100 in-oz of motor torque and thus all my "freeboard" in motor tuning was used up and thus a fault. Varying config settings and other stuff mentioned will not cure my problem.
The only fix is to modify that axis and do away with the problem. Finding the problem was very, very, very elusive. Now just need to get off my ask and fix it!
Forget about my problem though. Check your machine out and be confident that all is well, then apply the code to observe ( do post that code ).
You'll find the darn cuplrit.
RICH
RICH
-
Rich,
Now you got m thingking of my Z ballscrew lead, it was the noise on that particular/diagonal gcode that bother me.
I don"t know how to check, specially below .
"but after measuring the torque required to turn the screw, after some "manual similation" of code moves , i found it requires an additional 70 to 100 in-oz of motor torque and thus all my "freeboard" in motor tuning was used up and thus a fault "
My ballscrew Lead onZ is like 1 inch, it's not smooth when I push up.
I wlil do like you said, later this week.
Will post the gcode.
Thanks you again guys for your help, now it's up to me.
Cheers
C