I'm not even sure what to call this.

[Doanwannapickle]

Here's an odd behavior.  It isn't really hurting this part but somewhere down the line it may.  I thought you'd want to look into it.

I'm attaching three screen shots so you can see where I'm zooming into.  On the third screen shot you can see where several lines overshoot then one line is disconnected then everything returns to normal.  It makes the tap file do an odd dance.

I'll also attach the cb file.

Regards,
Walt

[10bulls]

Well, I'm afraid to say the problem is mostly *%?!@?! tolerances again.

In the attched screenshot I lowered the tolerance to 1e-6 and the overshoots went away.
Even at 1e-5 there were some small overshoots.

I say 'mostly' because, as you can see there is a missing arc in one corner.  Again, this shouldn't cause problems as the post processor should join up this small gap with a line move.
This may be related or a different problem.  I will use this as a test file to investigate.

The root cause of all this is that some geometric routines (such as intersection points between arcs and lines etc) need some measure of 'fuzziness' to work. At some point, I plan to tear the geometric functions apart and rewrite them to minimise rounding and precision errors so they are not so tolerance sensitive.  But this is going to be a pretty major undertaking and I can't see this happening for at least a couple of months, when I will have much more time to devote to CamBam.

One thing I can do in the mean time is to at least make the tolerances more maintainable.
At the moment, each mop has it's own tolerance value.  There is another under the machining options and a general tolerance value under options used for operations other than machine ops.
I plan to remove the mop tolerances and just get them to refer to the single value under machining.  I have also considered putting a warning message when tolerances < 1e-5 are used.

Thanks again Walt! The more test files I have that demonstrate this problem, the easier it will be to track it down.  This is a nice simple drawing too.

[EL34]

Man, 10bulls, just reading all the post here and the to-do list you have, I'd say you are stretched thin on the programming time?


Why don't you start a tip jar or some other means of collecting cash for your hard work.
I want Cambam to succeed.

[Doanwannapickle]

The first thing I thought of was tolerances so I set them to 8 or 10 and got the same problem so I discounted that.   

Turns out I didn't have the path width wide enough so I upped it to .2".  (needless to say that 3/32" end mill didn't last long plowing into 1/4" brass at 10 ipm)  This made it look like the problem was solved until I ran the file.  Same strange little dance.  Just needed to look at the corner even closer.   

Sure wakes you up when you're doing multiple passed like that and the cutter suddenly takes off in a direction that you KNOW it's not supposed to. 

How high can the tolerances go?  What would be the problem with just setting them there?  My default is 5.  I suspect part of my problem is that I'm working with such small items the size of the cuts starts to be close to the size of the tolerance.

Regards,
Walt

[10bulls]

How high can the tolerances go?  What would be the problem with just setting them there?  My default is 5.  I suspect part of my problem is that I'm working with such small items the size of the cuts starts to be close to the size of the tolerance.

Problem is, if tolerance are too small, you run into the other side of the coin, where lines don't intersect when they should and other problems occur.  I tried going down to 1e-7 on your file but then other bad things started to happen.
1e-5 usually fixes things, but in your case, you may want try 1e-6 everywhere.
Don't forget (for now at least), tolerances are also stored in the mop templates, so you need to make sure they are all set as well.

Yes, the scale does exacerbate the problem and imperial units makes things even smaller.  I did add thousandths to the drawing units, but I have not tested this much at all.  I'm not sure what gcode units code it would output, but the numbers would be in thousandths.  Is there a way of scaling gcode in Mach to say 1/1000 ?  Just a thought.  (Wished I called it 'mil' instead...gotta go clean my notebook screen now).

[10bulls]

Man, 10bulls, just reading all the post here and the to-do list you have, I'd say you are stretched thin on the programming time?

Why don't you start a tip jar or some other means of collecting cash for your hard work.
I want Cambam to succeed.

MrBean suggested something along these lines.
The way things are shaping up, the free version of CamBam will remain reasonably feature rich and unrestricted so that might be a way to help support it (and me) while work progresses on a commercial version.

My big regret is that I didn't get into CNC several years ago, before the 3 kids came along, when I (surely) must have had more spare time.  C'est la vie!