Messages

9061

CamBam help (General usage) / Artifact on importing Rhino .3DS files

« on: December 26, 2010, 01:47:03 am »

I imported this file, which is a demo file from Rhino 4.0.

I re-sized it, and the X/Y axes appear normal (about 11" long, and 4-or-so wide), but the Z height is quadrillions of inches high.

Huh?

LLoyd

9062

CamBam help (General usage) / Re: Draw a spiral without script

« on: December 23, 2010, 22:31:16 pm »

You say, "tortuous".  I say, "brilliant" (and pretty simple, too).

I'll have use for that.  Keep up this sort of work, and I'll not have need of my rotary table!

LLoyd

9063

Members Projects / Merry Christmas, in Walt's hand

« on: December 23, 2010, 21:35:10 pm »

Have a happy one, all.  And for those who don't celebrate it, be safe, and make metal.

LS

9064

CamBam help (General usage) / Re: Another fast plunge question

« on: December 23, 2010, 13:48:08 pm »

Thanks for pointing that one out... I am surprised it hasn't come to light sooner.  I suppose most controllers can handle missing variables in G0.

---------------
Yep... 'found one more good use for a very old machine!   

LLoyd

9065

CamBam help (General usage) / Another fast plunge question

« on: December 23, 2010, 02:27:05 am »

I set up an engraving job, with a "general" retract plane of 0.125" above the work, and a step-over plane of about 5-thou over the surface.

I set up the FastPlungeHeight to 0.125".  On the very first tool change, it did a fast plunge to 0.125 both before and after the tool change.  This may have been a plunge to the "retract height", because the next tool change switches from a drill to an engraver, an it did NOT do the fast plunge after the tool change.

I noticed that, although I set all the variables in the post G0 command to "non-modal" (no underscore), still, the post-processor didn't express the Z axis in the next G0 after the tool change.

I'm thinking it may be that I use an M26 for a tool change instead of an M6 (haven't tried to challenge it tonight), and the post-processor hiccoughs on that.  Any clues?

LLoyd
(here's a code snippet)

G70G90G17G40
G0Z.125
; Drill1
; T6 : .125
T6M26
S1000
G0Z.125
G0X1.4791Y4.9947
G98
G81X1.4791Y4.9947Z-.25F10.0
G81X1.4717Y2.2779Z-.25F10.0
G81X8.9986Y2.263Z-.25F10.0
G81X9.006Y4.9798Z-.25F10.0
G80
; Engrave1
G0Z.125
; T7 : .04
T7M26
S3000
G0X1.3149Y4.4409
G1X1.3149Y4.4409Z-.065F10.0

9066

CamBam help (General usage) / Re: Confusing arcs

« on: December 22, 2010, 23:44:20 pm »

Got the "long arcs" issue solved.  Thanks.

LLoyd

9067

CamBam help (General usage) / Re: Confusing arcs

« on: December 22, 2010, 14:25:56 pm »

Ok, Andy.  Got that.  Somehow, even after I read the CutViewer help, I missed that bit.  <sigh...>

Now...    Is there any way to handle the unsigned incremental drill depth issue we discussed the other day?

For instance, if I have a peck done thus:  G83 X4.0Y2.0Z-.25R.0625Q-.125F10,
The R2E4 expects to see no R value, Q as "Z"(also), and the depth Z value as unsigned, thus:
                                                         G83 x4.0Y2.0Z.25Z.125F10

Is there a way to make CutViewer honor that?  I went back over the docs, and they seem to suggest my writing my own .dll or .exe to do it.

LLoyd

9068

CamBam help (General usage) / Re: Confusing arcs

« on: December 22, 2010, 12:10:27 pm »

I should have said, "The BOSS4-7 controls honor incremental arc centers _from_the_starting_point..."...

OH! Andy you made me remember something.

Is there a way to make CutViewer honor the absolute arc centers?

Right now, if I wish to preview the machining paths, I must generate the g-code with the ArcCenters (Incremental) set first, view the work, then re-set it to (Absolute), and re-gen the g-code.

I cannot figure out how to make CutViewer work, doing otherwise.

LLoyd

9069

CamBam help (General usage) / Re: Confusing arcs

« on: December 22, 2010, 12:01:55 pm »

What arc center mode does the R2E4 expect?  CamBam can output absolute or incremental arc centers by setting the ArcCenterMode option listing in the properties of the Machining object if that helps.
CamBam computes I & J from the arc start point.
While looking at CutViewer turn options I noticed options to set IJ from arc end point as well as start point which was new to me.  I was planning a similar option for the post processor in 0.9.9 but I am not sure of what controllers this would apply to.
-------------------
Andy, the documentation for all of BOSS4-7 call out incremental arc centers, yet the BOSS9 (at least the one I have) seems to confuse the issue.  It honors absolute arc centers, and is capable of (near) 360-degree arcs in either direction using G2/G3 -- yet, they kept the G75 multi-quadrant control??  If that was for backwards compatibility, then you'd have thought they'd also have kept the incremental arc centers for single-quadrant circles like the earlier BOSS machines.

I haven't found it yet, but I'm almost betting there is a jumper on a board somewhere that allows "factory" selection of which mode it will appreciate.

LLoyd

9070

CamBam help (General usage) / Confusing arcs

« on: December 22, 2010, 01:05:04 am »

I have had some trouble with some weird arc issues on my R2E4, and in trying to resolve them, I tried an experiment in 9.8g

Working in inches, I created a "perfect" circle, diameter 2, at center 1,1. (draw circle)

I divided it "exactly" with a line from X1,Y2.25 to X1,Y-0.25. (draw polyline, stopping after the first segment)
I selected everything, did a "break at intersections", and deleted all three residual parts of the straight line.  So now I'm left with two semi-circles of 180-degrees, centered at 1,1.

I set up the mops as "engraving", modifying only the stock surface and depth so the g-code would make only one pass around the curves.  I expected two 180-degree arcs centered at 1,1.  I got instead:

(starting at X=1,Y=2 and in absolute mode)

G3X.5Y1.866Z-.015I.0J-1.0F30.0  ; \
G3X.5Y.134Z-.015I.5J-.866F30.0  ;  --   Three CCW arcs totalling 180 degrees
G3X1.0Y.0Z-.015I.5J.866F30.0 ;     /
                                            ;   followed by
G3X2.0Y1.0Z-.015I.0J1.0F30.0 ; \
G3X1.0Y2.0Z-.015I-1.0J.0F30.0; /   Two (exact) CCW 90-degree arcs.

Huh?

The R2E4 issues seem to have to do with a confusion in the BOSS9 controller about relative distance to center vs. absolute center.   It works on some short, small-radius arcs, and fails on other gentler curves.   But this just confuses me.  How come I didn't get two 180-degree arcs?

LLoyd

9071

Post Processors (*.cbpp) / Re: Forcing post-processor to not generate arcs

« on: December 21, 2010, 14:16:40 pm »

That's cute and really smart.  My R2E4 has trouble with long, slow arcs.  Little short ones (like when cornering blocks) work fine, but smooth "calliographic" curves give problems with e-stops.

That trick with the minumum arc length works nice!  Thanks.

LLoyd

9072

Post Processors (*.cbpp) / Eliminating hard-coded data

« on: December 21, 2010, 12:55:22 pm »

Andy,

My old R2E4 does not have (and cannot swallow) a G98.  I must do a G00 to the retract plane in place of it.

I have tried defining the G98 in post, a la:  <G98> G00 Z0.125 </G98>.  But this is to no avail.  Apparently the G98 code is hard-coded.  This same issue might apply to other hard-coded items.

My only other experience with post editors had the post file defining *all* the potential G and M codes;   Some would even permit you to create new ones (like special canned cycles), using the extant variables and your own text.  You just leave the defaults alone if you need not change what's already defined. 

Any suggestions on how I might handle this in post?  Right now, a sed filter is cleaning them out. (yep... still got an old copy of MKS tools  )

Thanks,
LLoyd

9073

Post Processors (*.cbpp) / Re: Swapping codes in post processor

« on: December 19, 2010, 02:00:58 am »

Is there an easy way to get G70/G71 instead of G20/G21 for imperial/metric? I thought that the <G0>G0</G0> trick might have worked for me (using <G21>G71</G21>), but alas, no. Perhaps this could be extended to handle other codes? Thanks and any help appreciated.

-------------
FWIW, Peter, Andy and I had a conversation about this very thing last week.  He has some ideas that might solve the matter in your (my) favor, if implemented in an  update after 0.9.8g.

LLoyd

9074

CamBam help (General usage) / Re: What I see on the Cam Style Video but can't find on my version,

« on: December 19, 2010, 01:54:57 am »

Yeah, Bob, I have to agree.  Andy is tops, and the software is, also.

I have to bank Monday, then I'm buying the package. 

Andy, I cut my first "real" metal with CAMBAM this weekend, after "air milling" for about a week.

I still have those obtuse Bridgeport text and Z translation issues, but so far, they are pretty easy to solve with a text editor.

OTOH, I got the old R2E4 drip-feeding successfully, and was able to run a part directly from the CAMBAM (edited) output that turned out just exactly like the drawings!

THANKS!  This is the upcoming HSM package, and HSMs have a big voice among job-shop owners, too.

LLoyd

9075

Members Machines / Re: Drip feeding an authentic R2E4 -- help!

« on: December 18, 2010, 19:34:53 pm »

I intend to upgrade/retrofit this machine when I can afford a "kit" solution.  I don't have the time to do it from scratch.

In the meantime -- ARMANDO!  THANKS!  I got it working this a.m.  The "manual" is useless, so it took a lot of expermenting, but it works.  I air-milled a part that is over 53K of code, and the machine never skipped a beat.

I also have some information on the protocol now.  I will document it as time permits, and if my skills are up to it, I'll write a plug-in that will manage it.  If not, I'll submit my findings so someone else can.

LLoyd