Messages

9031

Related Softwares / Re: Is this a bug?

« on: January 08, 2011, 22:45:02 pm »

Andy, good news for you, but it has me stalled:  This is a CutViewer problem.

It milled fine in wax on the R2E4.

This "ball" project was a way to proof some problems I'm having on a more complex job ("real" work).  I got those weird paths on that job (in simulation), and did the ball profiles to find the crux of the issue.

As I think back, once I fixed the absolute centers on arcs issue, I don't recall actually having milled a bad arc.

Please forward this as a CutViewer problem.  FWIW, I'm not sure it's actually related to the speed change, but rather that CutViewer might be taking that or some other part of another command as data for a previous one.  I think I have had that aberrant arc appear in other parts where there was no tool change, but where a change of strategy from (say) flat pocketing to 3-D profile pocketing was being done, but where I had edited out the tool change as superfluous.

LLoyd

9032

Related Softwares / Re: Is this a bug?

« on: January 08, 2011, 17:06:02 pm »

Although I am not sure why you are having problems with the Bridgeport?
What problems are you seeing when you run the file?

--------------------------
Andy, I'll be honest and say that I have not yet air-milled that last version of the files.  In the progress getting to this point, though, any time CutViewer blows up on an arc, my machine does, too.

This evening, I will run the part, and see what the machine does, then report back.

It _is_ odd, and the appending of the two MOps separately into one successful file sort of confirms that this might be a CutViewer problem.

Thanks, also for that 3-D finish fix.  It's an annoyance, only, but certainly would lead to future service requests.

LLoyd

9033

Feature Requests / Re: Part or machine operation tag info into G-Code

« on: January 08, 2011, 16:29:53 pm »

Let's try not to offend those that you don't even know...

dan
----------------------
There was no intent to offend, and I apologize if it came over that way.  I live and die by documentation.  Any employee of mine not willing to follow "the process" isn't an employee anymore, period.  (We manufacture explosives).  The machine work is to build tools for that purpose.

I guess I just didn't see it from your perspective.

LLoyd

9034

CamBam help (General usage) / Re: Guidance on fast stock removal via drilling

« on: January 08, 2011, 16:26:22 pm »

I think it is a good idea though and shouldn't be too difficult to implement.  I'll put this on the list for 0.9.9 as there are a few other 3D operation changed planned for then.
--------------

WOOT!  That will save a bunch of expensive bits in favor of cheap ones!  Thanks!

LLoyd

9035

Feature Requests / Re: Part or machine operation tag info into G-Code

« on: January 08, 2011, 13:07:13 pm »

quick off the top of your head what was tool #3 for the google part - that you programmed 6 months ago?

-----------------------------------------------------------------------
That LIST would be maintained in the folder (paper or computer) containing all the specs for the part, along with a bill of materials, a job-cost estimate (even if it was just a milling time figure, when you're not billing it out), and all the other "notes from me to me" that one makes when designing an actual part (as opposed to an exercise).

It would be nice to be able to drop comments from within CAMBAM, but it's also simple to do that within an editor, like in the editor of CutViewer, while you're proofing the run.

There's no chance you'd just give a machine operator a machine with a g-code file alreadly loaded in, and just tell him "make this part".  Not even in a production environment.

(Well... maybe you would ?)

LLoyd

9036

Feature Requests / Re: Part or machine operation tag info into G-Code

« on: January 08, 2011, 02:53:40 am »

once you get more than a couple different tools involved in a part it's easy to forget to do tool change when doing the actual machining.

----------------
That confuses me.  How do you "forget" to do a tool change when the machine stops and asks you for a new tool (and gives you the tool number)?

LLoyd

9037

CamBam help (General usage) / Re: Guidance on fast stock removal via drilling

« on: January 08, 2011, 02:50:53 am »

those profile point-fill tools work just fine for filling up the geometry of my part with dots, but when you turn all those dots into drill MOps, they must be all the same depth.  They will no drill down to and stop at a 3-D surface.

No real way to do a drilled stock clearance (yet  ).

LLoyd

9038

Related Softwares / Re: Is this a bug?

« on: January 08, 2011, 02:47:20 am »

If I try waterlinefinish in place of waterlinerough, I get error message from windows when generating toolpath !

That's because of another _suspected_ "bug" that I haven't yet gotten a read on from 10bulls.  If the stock surface isn't exactly at or just a few thousanths of an inch above the top of the profile surface, Waterline Finish reports that odd error, instead of just telling you that the stock surface must be near the profile surface.

LLoyd

9039

Related Softwares / Re: Is this a bug?

« on: January 08, 2011, 02:43:29 am »

Those MOps work in absolute-center mode.  Change your cutviewer configuration file _gcode.nci
entry from IJkformat_abs=Center-Start to IJKformat_abs=Center, and you'll see what I'm seeing.

LLoyd

9040

Related Softwares / Re: Is this a bug?

« on: January 08, 2011, 02:14:28 am »

David, to me your result looks more like a configuration problem than the bug I'm suspecting.  It's perfectly regular, where the "broke" file gives me a good milling sim except with one errant arc that zooms outside the profile.  If you change _gcode.nci value IJkformat_abs=center-start to IJkformat_abs=center, your Cutviewer should act like mine.

Here's an experiment I did that might tell more:

I generated the toolpaths for both MOps, then I disabled one, generated G-code, then flipped to the other and generated g-code, then enabled both and generated it for both MOps.

Each individual "chunk" worked fine in simulation.  Editing (splicing) them together (only removing redundant setup and file-end stuff) resulted in a combined file that worked fine, too.  But when CAMBAM generated the combined g-code itself, it errors in simulation.

I think this is a bug in how CAMBAM treats the transition in g-code from the first to the second MOp.  It is the "last circle" in the 3-D profile MOp that goes wild...

LLoyd

9041

Related Softwares / Is this a bug?

« on: January 08, 2011, 01:31:54 am »

I have attached two .cb files... one that will simulate just fine, and the other which drives cutviewer crazy.

There is only one difference between the two.  In the "works" file, the 3-profile MOp cuts to -0.35"
In the "broke" file, the same profile cuts to -0.36".  Nothing else did I change.

Is this a bug?  Or is it something really fundamental I don't understand about overlapping geometries?

The problem is, I cannot deliberately make an arbitrarily-deep cut on that profile.  Sometimes it works, other times it crashes cutviewer (and my real mill).

Thanks,

LLoyd

9042

CamBam help (General usage) / Re: Ostensibly smooth arcs being chopped up into little moves

« on: January 08, 2011, 01:24:08 am »

Thanks very much.  I will study what you have done!

LLoyd

9043

CamBam help (General usage) / Re: Guidance on fast stock removal via drilling

« on: January 07, 2011, 20:45:27 pm »

LLoyd.
Have a look here.
http://www.cambam.info/doc/dw/0.9.8/tutorials/Drilling.htm

Martin.

Yeah... RTFM!    I did view that a week or so again, but I didn't yet try it.  Wondering if it will work on a surface profile, as well....
 
I'll have to try that, and see!  Thanks again.

LLoyd

9044

CamBam help (General usage) / Re: Ostensibly smooth arcs being chopped up into little moves

« on: January 07, 2011, 20:42:16 pm »

I haven't got that file, but I think CamBam is just following the mesh geometry of the ball.
See the screen shot of how you get an Arc-Line-Arc-Line... on the toolpath display, as it follows each facet of the sphere.

Have you got a Constant Velocity option on your machine controler that you can switch on?

Martin.

Ahhh... yes.  That might explain it.  I don't have a "constant velocity" mode, per se, but my machine does have a "decel off" mode setting.  I am not presently invoking that option.  I can try it.


One thing confuses me, and this may be an artifact of that, also.  I did a transform, resize on that mesh dome, increasing it's diameter by a few percent (to make the ball bigger).  The MOps all look good in CAMBAM, but CutView Mill goes NUTS with it, making odd curves, arcs outside the work area, and even odd "stutter-step" paths where the bit raises and lowers by the depth increment, but does not cut a continuous path around the profile.

So, if I were to generate a mesh with vertices and faces smaller than my machine's resolution, other than clogging my file up with a HUGE mesh definition, would that work to smooth out the profile?

Thanks,
LLoyd

9045

CamBam help (General usage) / Ostensibly smooth arcs being chopped up into little moves

« on: January 07, 2011, 13:23:46 pm »

Back on the ball-in-a-cage again 

When running the MOps that pocket down to the top of the ball, everything goes pretty smoothly in what look to be 120-degree (or greater) arcs.   The machine more or less moves in smooth, complete circles. But from the top of the ball down, almost every arc move is less than 5-10 degrees.    Yet, I cannot see why, since each "turn" around the ball is no different than it was when doing the pocketing passes.

All in all, the accuracy seems OK, but it means tons of stop-starts for the tables, and lots of acceleration and deceleration time that grotesquely bloats the milling times.

So the question is, is there something I can do in the CAM stage to maximize the sizes of the arc, or this this something so deeply embedded in the inner workings of CAMBAM, that I cannot change it?

Thanks,

LLoyd