Freesteel Blog » The toolpath collision point with an engagement sweep

The toolpath collision point with an engagement sweep

Thursday, January 10th, 2013 at 6:30 pm Written by:

Have just checked in 400 lines of the function CheckPathSegmentCollisionSweepArc() to go with the 150 lines I had done in CheckPathSegmentCollisionSweepLinesegment(). The line counts are a bit unfair because there are several sets of duplicated code for the clockwise and anticlockwise, in and out configurations.

This is to do with the new feature of toolpath re-ordering in the Adaptive Clearing algorithm, the culmination of the ideas I worked out with Martin on the train back from Copenhagen in October.

One of the fundamental routines requires considering a length of cutting toolpath P and comparing it with a length of cutting toolpath Q and its adjacent linking toolpaths from later on in the total toolpath, and deciding whether it is safe to do Q before P instead of after it.

Basically, it’s safe to reorder so long as the circular profile of the tool as it sweeps along the Q path does not hit any of the material removed by P.

Our first approximation of the function simply returned True when the bounding boxes of Q and P were separated by more than the sum of the two tool radii, and was good enough to demonstrate that the rest of the re-ordering feature was going to work. (I’ll outline that deceptively simple algorithm at a later date.)

But the results would be tighter the better we approximate of the material removed by the path P.

Our first attempt used the measured engagement value set at every node of the path P as a byproduct of the Adaptive Clearing algorithm.

The plots of it were beautiful, with the sequence of engagement arcs looking exactly like the scores on the metal, but I failed to take a screenshot of them. The problem was determining how frequently one should sample along the toolpath. I don’t like fudging matters by just plucking a small number out of the air that would probably work, but which would leave an unnecessary upper bound for performance. And I couldn’t guarantee that the engagement width along the toolpath between its nodes was never spike up to just below the maximum engagement angle, and then back down to a small value before the next node.

So I decided to assume the value was always the maximum engagement angle along the toolpath — which is already sampled at the widest rate possible specifically to not exceed this engagement angle. That makes it easy. It is an over-estimate, but it is controlled. Most of the time the engagement angle is close to the optimum. And when you want to favour speed of calculation over accuracy you leave a wider margin between the maximum and the optimum. And so it is reasonable for the approximation of the material removal area to degrade correspondingly (though always erring on the side of caution). When you tighten things up, everything should tighten. When they loosen, all parts should loosen.

The geometry is explained in the picture above. We are looking for the point along path Q where the tool profile collides with the material removed by path P. When Q is a cutting path, we just need to know Yes or No. When it’s No we cannot reorder Q before P. When Q is a linking path, we need to trim it back so that we can use the safe part of it to guide the toolpath away from the stock and calculate a new linking move that avoids all previously uncut stock.

Obviously we break Q down into line segments and arcs, and P down into arc and two line components called fsengagementsegsweep which is composed of the red arc (with its two end points) and the two parallel orange lines whose end points are embedded within the arcs and so do not need to be tested. There are 5 different ways for the circle profile to be in contact with an fsengagementsegsweep.

The function CheckPathSegmentCollisionSweepLinesegment() dealt with the line segment linear motion of one of those purple disks along Q to the soonest a point where it makes contact in one of the five ways with the fsengagementsegsweep‘s generated by path P.

But then what to do with the arcs on the path Q (usually quite big ones when they involve linking motions)?

The first version is just to approximate the arcs to short line segments and call CheckPathSegmentCollisionSweepLinesegment() for each one of them. But that’s horrible. What tolerance do you use? There’s no right answer, so what you choose will forever be obstructed from optimality.

Given that it is a soluble problem — circles on circular trajectories making contact with other circles — I’ve done it properly and given the analytic answer. But it’s been two days of deeply tedious work where I could be distracted by anything.

Here are some of my trial experiments. The yellow line is the cutting path P with its red and orange material removal areas. The black lines are repeated instances of the path Q — specifically an arc segment — that I am testing the function against. I have tried them both in the clockwise and anti-clockwise directions and plotted in green the point and disk of contact with the material.

It’s Thursday evening, and now it’s done at last. I’ve got all of Friday to play with other things, annoy other people in the company with emails, and track information down in EU documents.

That reminds me: I haven’t got an answer back from technical support after they forced me to change my password after my first 90 days with the company. I asked if they had any idea what proportion of employees have to write their passwords down because of this policy — even though they are instructed not to. In other words, are they wilfully ignorant of the anti-security consequences of their supposedly pro-security policies?

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>