Hello friends~
Can anyone explain why my Shark Pro Plus slows down for curves? It seems to make no difference where my feed rate is set, it will always move much slower around a curve than going straight!
Using a pocket toolpath, offset (as opposed to raster), the design is a large pocket cutout with letters left standing out in the middle.
I'm referring to when it goes around a letter, it slows down maybe 50% on a round letter, but on an L or I, it will move full speed. In a production environment, this seems to be quite a waste of time! What can I do about it??
Thanks!
Slows down for radii
Moderators: ddw, al wolford, sbk, Bob, Kayvon
-
Consultingwoodworker
- Posts: 333
- Joined: Fri Jul 02, 2010 7:37 am
- Location: Nashville area
- Contact:
Re: Slows down for radii
Every move of the router, of ANY CNC router, includes a 'ramp up' and a 'ramp down' command. Obviously, you do not want the machine to slam from zero to full speed instantly, and stop instantly at the end of a move. Even in full sized steel framed machines weighing thousands of pounds need to do this.
The settings in your machine may be off, but it is not unusual to see the system slow into corners. But sometimes how the vectors are set up can alter the machine performance. For example, a curve (such as your radii) can be 'seen' by the software as a single entity, a quarter circle, or as a series of very tiny lines forming a quarter circle. In that case, the machine will cut the radius as a series of short line segments, and of course, in none of them since they are very tiny, does the machine ever reach full speed. It is constantly ramping up and down in speed since each line segment is treated separately.
This is often caused by poor conversion from raster to vector or by improperly saving a .dxf file from other formats. I can look at your G-Code and tell you instantly if this is the case for your program. The curves in the corners should be represented with one line of code. If they are represented by many lines of code, then I know that the .dxf file was improperly converted.
Ralph
The settings in your machine may be off, but it is not unusual to see the system slow into corners. But sometimes how the vectors are set up can alter the machine performance. For example, a curve (such as your radii) can be 'seen' by the software as a single entity, a quarter circle, or as a series of very tiny lines forming a quarter circle. In that case, the machine will cut the radius as a series of short line segments, and of course, in none of them since they are very tiny, does the machine ever reach full speed. It is constantly ramping up and down in speed since each line segment is treated separately.
This is often caused by poor conversion from raster to vector or by improperly saving a .dxf file from other formats. I can look at your G-Code and tell you instantly if this is the case for your program. The curves in the corners should be represented with one line of code. If they are represented by many lines of code, then I know that the .dxf file was improperly converted.
Ralph
Re: Slows down for radii
Thank you!! That totally makes sence, and yes, the G-code for the curves is many many lines of code. But I don't understand how it SHOULD be...? What am I improperly saving? 
Re: Slows down for radii
I'll try and add a little to this and hope I can explain it well enough.
The cnc controller analyzes the g-code and looks ahead at upcoming moves in order to plan the best path and speed. This is a normal and desired function of the controller.
the info it has to go on is :
the maximum speed each axis the machine can move,
the maximum rate each axis can accelerate and down,
the desired feed rate,
the desired path you want it to follow,
the amount of deviation from the ideal path you are willing to accommodate.
The first two of these are set in the controller and were not meant to be easily user adjustable on the Shark.
The rest are (or can be) set in the g-code file.
Given this info, the controller does "trajectory planning" to determine what actual speed it can go, given the path you are asking for.
To use an automotive analogy, lets say the car can go 150mph maximum, and you want to go 70mph (feed rate). The course you want to follow is a long straight, a tight slalom, and another long straight. etc.. The trajectory planner will most likely let you run full desired speed (70) on the straight. Because it "looks ahead" at the upcoming G-code "down the road a bit", it slows down slightly before and during the slalom, and resumes full desired speed in the next straight. The tightness of the curves will determine how much the machine thinks it needs to slow down to stay on the path. The more "sloppiness" you can tolerate, the faster it may let you go through the turns, but your part will have some dimensional variation from the ideal. A long large arc may run at near full desired feed rate, where a small tight arc will require the machine to slow down before the turn in order to get through the turn accurately. The tighness of the turn is a major factor in how the machine will try and trace that path. Also, it is looking at these moves in all three dimensions at the same time. A straight line with a step up and then down in the center will have the machine slowing down slightly to get the step edges sharp. So if you change your feed rate to 150, the machine will still slow down to what it thinks the maximum speed for the turn is, no matter what you asked for as feed rate. If the machine calculates it can go 40 in the slalom, it will go 40 , no matter what you asked for.
The number of segments making up the turn will affect the surface smoothness of the arc, and can affect the speed if you are telling the machine to trace that path "exactly" as many straight segments. but no matter how the curve is drawn, the machine will need to plan ahead for it, and slow down if your feed rate is more than the machine can trace during direction changes.
When the shark is slowing down, it is telling you it needs to to maintain the accuracy you desire. So you can accept that speed, or alter the allowable sloppiness to let it go faster, or get a machine that can run at higher speeds during tight turns. However, like cars, performance usually adds cost. A Prius will never "corner" like a Lotus.
I hope this helps.
Bob
The cnc controller analyzes the g-code and looks ahead at upcoming moves in order to plan the best path and speed. This is a normal and desired function of the controller.
the info it has to go on is :
the maximum speed each axis the machine can move,
the maximum rate each axis can accelerate and down,
the desired feed rate,
the desired path you want it to follow,
the amount of deviation from the ideal path you are willing to accommodate.
The first two of these are set in the controller and were not meant to be easily user adjustable on the Shark.
The rest are (or can be) set in the g-code file.
Given this info, the controller does "trajectory planning" to determine what actual speed it can go, given the path you are asking for.
To use an automotive analogy, lets say the car can go 150mph maximum, and you want to go 70mph (feed rate). The course you want to follow is a long straight, a tight slalom, and another long straight. etc.. The trajectory planner will most likely let you run full desired speed (70) on the straight. Because it "looks ahead" at the upcoming G-code "down the road a bit", it slows down slightly before and during the slalom, and resumes full desired speed in the next straight. The tightness of the curves will determine how much the machine thinks it needs to slow down to stay on the path. The more "sloppiness" you can tolerate, the faster it may let you go through the turns, but your part will have some dimensional variation from the ideal. A long large arc may run at near full desired feed rate, where a small tight arc will require the machine to slow down before the turn in order to get through the turn accurately. The tighness of the turn is a major factor in how the machine will try and trace that path. Also, it is looking at these moves in all three dimensions at the same time. A straight line with a step up and then down in the center will have the machine slowing down slightly to get the step edges sharp. So if you change your feed rate to 150, the machine will still slow down to what it thinks the maximum speed for the turn is, no matter what you asked for as feed rate. If the machine calculates it can go 40 in the slalom, it will go 40 , no matter what you asked for.
The number of segments making up the turn will affect the surface smoothness of the arc, and can affect the speed if you are telling the machine to trace that path "exactly" as many straight segments. but no matter how the curve is drawn, the machine will need to plan ahead for it, and slow down if your feed rate is more than the machine can trace during direction changes.
When the shark is slowing down, it is telling you it needs to to maintain the accuracy you desire. So you can accept that speed, or alter the allowable sloppiness to let it go faster, or get a machine that can run at higher speeds during tight turns. However, like cars, performance usually adds cost. A Prius will never "corner" like a Lotus.
I hope this helps.
Bob
Re: Slows down for radii
Great explanation! Thanks.
Where can I set the tolerable "sloppiness"? I think it's being plenty precise, I'd like to mess with it a bit.
Where can I set the tolerable "sloppiness"? I think it's being plenty precise, I'd like to mess with it a bit.
Re: Slows down for radii
some info on the precision adjustment can be found here:
http://www.cncsharktalk.com/viewtopic.p ... 83&p=19237
http://www.cncsharktalk.com/viewtopic.p ... 83&p=19237
Re: Slows down for radii
If your circles/arcs are currently made of several small straight vectors, there is an Edit option in VCarve to "Curves Fit Vectors". You get a choice of circular arcs or bezier curves, and either (results with each may vary) will turn those choppy straights into arcs that the post processor/controller can cut more efficiently. The "arcs" in the post processor names means it will handle arcs as it encounters them with one or two G-code commands rather than one for each short line segment they used to be composed of.
I help students of mine optimize their typically imported DXF files for this very reason. You can considerably reduce the cut time for any part that has lots of curves in it.
I help students of mine optimize their typically imported DXF files for this very reason. You can considerably reduce the cut time for any part that has lots of curves in it.
-
Consultingwoodworker
- Posts: 333
- Joined: Fri Jul 02, 2010 7:37 am
- Location: Nashville area
- Contact:
Re: Slows down for radii
As for what you can do to alleviate this, it is in the preparation of the drawing.
How are you preparing the drawings, and converting them to G-Code?
When I draw in DeltaCad and save as a .dxf, it gives me a couple options for how to handle curves and splines. That is where you are likely to find the issue.
Ralph
How are you preparing the drawings, and converting them to G-Code?
When I draw in DeltaCad and save as a .dxf, it gives me a couple options for how to handle curves and splines. That is where you are likely to find the issue.
Ralph
Re: Slows down for radii
I'm just using the V-carve software that came with the machine both to draw and to create G-code.