Normalizing speed along path

Marco,
You can deal with this problem in a number of ways. A very basic way could be a script that would parse your code and estimate the distance between subsequent points and when it encounters a length greater than X then divide that distance into smaller line segments by inserting a number of equidistant, colinear points(LIN commands)set by you. That forces the robot to go through dense in points areas all the time and maintain a more or less consistent speed. More sophisticated scripts could adjust speeds and acceleration on a per-point almost level where needed, considering again changes in length between two points.
A more practical way is to choose for roughing especially, contour milling strategy. Never worked with Sprutcam but I am sure they have it. Contour roughing will output for the most part curves (hence dense in points)that they are offsets of the intersection curves of a plane with the geometry of the part. If there is an area in your part that is planar then it will output straight lines again as a contour but you can trick it by placing only for the roughing a dummy surface geometry with a slight convexity( not more than a mm) right on top of that area which will brake the linearity of the contours and get you curves again instead of lines. This method will give you a much more consistece in speed Toolpath but at the cost of very large files.
I hope you found this a bit useful.

You can try this option:

vvelicov:
So in Sprutcam you can set a max length between two subsequent points and it will break up a long line segment into a collection of shorter line segments? That's great.

Just be careful -- robots don't work well with large numbers of very small moves. You'll need to work out the best compromise between "too many tiny moves" and "moves too large for precise path control."

When the movement is not smooth enough i am increasing $APO.CDIS - that improves the transition between the points

Yes, but even with $APO_DIST, it's possible to generate a path with points so close together that the path planner chokes, or the interval falls below $FILTER.

Also keep in mind, even if $APO_DIST is set to 100mm, if your point-to-point distance is only 5mm, your actual approximation radius is only 2.5mm.

SkyeFire:

I looked up the $FILTER system variable. Would you be able to elaborate a bit on the effect of choosing a certain value from the range of integers 0-16, and how the magnitude of that value would affect acceleration versus some other smaller or larger value?

Many thanks in advance.

Quote from KonstantinosP

SkyeFire:

I looked up the $FILTER system variable. Would you be able to elaborate a bit on the effect of choosing a certain value from the range of integers 0-16, and how the magnitude of that value would affect acceleration versus some other smaller or larger value?

Many thanks in advance.

It's been a while, and the documentaiton I recall was a bit contradictory, but the basic idea of $FILTER is that it established a minimum amount of time (in IPO cycles, IIRC) any motion command must be spread across. The idea is to force a certain minimum degree of motion smoothing, even under RSI. Think of it as a small low-pass filter on the motion planner.

In effect, if a sequence of three motions (A->B, B->A, A->B) is programmed such that the motion between the points takes less time than $FILTER dictates, the motion planner will slow the motion down so that it is "stretched" out enough to take as long as $FILTER requires. Reducing $FILTER can allow the robot to jerk hard enough on closely-spaced motions that it can damage itself, especially under RSI control.

Quote from Marco

1) After one day of milling and tuning my CAM to get hi precision details I still cannot get sprutcam to do not break big arcs in tiny segments and get the robot slowing down to much. The problem is important as you calibrate spindle speed according to feed speed as well and I'm noticing that tool is overeating when the robot slows down, but I cannot slow spindle speed down otherwise, on fast paths, spreed would be too low... The geometries I export to sprutcam are arcs, so there must be something in sprutcam to control this.

2)I guess I cannot use $APO.CDIS as I understand (maybe I'm wrong) that it approximates corners by a certain distance, which means that I'm gonna loose precision in details.

3) I checked the $filter variable and I guess that for milling operations it could be very important to reduce vibrations due to speed and direction change. How doe it works? The highest the value the smoothest? Where I should place this variable?

1. Any chance you could control the spindle speed dynamically, so that it speed up and slows down along with the robot's linear speed?
2. I don't know enough about SprutCAM, but you might be able to use Spline motions?
3. See my other post. Normally, this variable is set at the factory and never altered except by very high-end users with very exotic requirements. I only toyed with it briefly on one project years ago. In your case, I don't think you want to tamper with it. It's just a matter of being aware that programming a series of very small, tightly-packed motions might behave other than expected, in part due to $FILTER (and other motion-filtering safeties in the robot).

Hi Marco, did you asked the Sprutcam team for help? Can'r you use arcs? I think it is switched into the postprocessor - give it a try if you didn't till now.
As about the $APO.CDIS - yes, it rounds the corners, but in very small scale... it helps me when the points are too dense to avoid wobble movements
It is not a problem with Sprutcam - it happen to me in Powermill as well. But it shouldn't eat more material when slowing down as it should follow the surface? That is a bit strange... What speed are you using to cut? And material? It sounds like with the speed on the lines you are not cutting all the material may be? Did you check the accuracy of the robot?

Do you have Use arcs etc switched on in your machine parameters?
Like in the attached photo?

Marco:

I think we all had similar issues with the robot dropping the feed rate while entering parts of the path very dense in points. I believe your problem is more pronounced in roughing, especially if your strategy involves mainly straight paths and only some areas, probably around the part, where the path is curved and the density of points very high. If you planned your feed rate for the entire program based on how fast the robot moves over long straight lines with only two points basically defining the two end points, then it comes without surprise that it becomes painfully slow around tight curves and dense in points areas.
One solution would be to plan your speed based on the slowest areas instead. Try the following test. Generate a Toolpath with two straight lines, both 1000mm long. The one it only consists in two end points. On the other line space out points as near as the tolerance of your tool set in CAM. So if say your tool is set at 0.1mm tolerance then put on a 1000mm line 10000 points 0.1mm apart. (By the way, if you are milling large scale with soft materials and large tools, 0.1mm is a ridiculous number to set your tool tolerance by, but I put it as a worst case scenario).
Run the two lines at the same feed rate with a timer. See how much the speed drops. Divide the min into the max and this is your scaling factor for adjusting your rates in your program.
Clearly now the problem transfers from the slow areas to the fast areas that now become extremely fast. If you now read again my previous post to your question, it will probably make more sense and you can get an idea of how to deal with it. Once more, the idea is to keep your paths everywhere (reasonably)dense in points so the robot will never have the chance to move as fast as it can, and program your speed as we said based on its speed through the slowest areas but adjusted upwards using the scaling factor found as said.
Of course that would result in a much heavier file but your feed will become much more consistent.
The added benefit of having paths with consistent high density in points is the following: it will enhance path accuracy if you ever decide to calibrate your robot for positional accuracy with companies as Dynalog or RoboDK. If you have an error compensation filter that can take the robot safely with accuracy on two subsequent points, unfortunately if they are way apart the one from the other, nothing can assure you that the robot will travel on a dead straight and positionally accurate path whereas if the path is dense in points, then all these points have already been filtered and error-compensated, hence you travel on a straight line.
I hope that makes some sense.

I think you have to use C_VEL instead of C_DIS.
This will keep your milling speed constant.
Set your postprocessor to write lines with the end C_VEL.

Hi Marco, I'm also in need of finding the best settings for wood milling.

Did the use of C_VEL eliminate those nasty vibrations ?

What value for C_VEL did you find was the best compromise ?

Thanks,