I'm just wondering whether the general consensus on how Xp's initial plane and retract plane works for machine cycles is correct for your machine?

I make it work by forcing values into the cycle wizard that do not exactly match anything in the real world. What I see in the output code is that the initial plane is being subtracted from the clearance plane as though it were an incremental value, whereas I actually need them both to be absolute values.

Does it seem to be right from where you are working from?

Example: Initial plane input 0.4
Retract plane 0.2

Output in code is:
Retract plane is at Z.2 absolute, but initial plane is Z0.2 absolute.

Hu,
You've been messing around again, Haven't you?
The Haas post works ok.

Example: Initial plane input 0.4
Retract plane 0.2

Output in code is:
Retract plane is at Z.2 absolute, initial plane is Z0.4 absolute.

Sorry, looks like you get the short end of the stick again.:frown:

Here's what you use, is this correct?

{_MODE} G81 {Z} R{CT} {F}

Here is what I use:

Z{CD} /R{CT} /T{_DWELL} G81
/Z{CP}

This is because I need to see the move to the initial plane immediately after the cycle is called, to begin the autocycle.

I just think it is weird that some math operation is carried out on {CP}

I think it is me all right :)

I'm going to redo my setup of the drill cycles. I think maybe I should create a new parameter for my surface height, rather than trying to pull it out of those other variables.

The other thing I overlooked, is that the Z rapid height has to be higher than the retract height, or I'll get that "capping" effect.

Hu,
What you have listed is correct. It is the standard haas post cfg.
But I think your problem comes in when you get to the "cycles" box. Let me try to explain.

If you look at use the Haas post, (note you have to select the post, ie haas or shadow, before you use the machine cycles) and select your points then the tool, then clearance, you will get to the cycles box. This is where there is a difference between the two.

The Haas cycles box has only: "retract mode" to check.

The shadow cycles(the one you sent me) has:
Peck dist/z
Dwell /t
Safety......../z (wouldn't this be the Retract plane?)

I tried your shadow post and I get the same results you do.

I think this extra info from the cycles box is what is causing the Heartburn. But that is only a guess. I have messed around with different values in both of the boxes , but I am not able to make things work the way you would like.

Hu,
I miss spoke in the above post. The extra boxes are under the G83 cycle not the G81. Shame on me.:o

Thanks WMS for your input.

I fooled around with it for a while longer, and the only thing I could do was create a new parameter to hold what I would call the initial Z start, which should logically be the same as the Drill-initial plane but for whatever reason, that variable does not contain the fixed amount as taken from the user input.

It is no problem to do it this way, I just get another variable to define later in the cycle's "extras" field.

I only got to messing with this today because I was drilling some holes that started on a surface well below my Z0, and the negative numbers involved were driving my drill cycles wacky.
But anyway, now I have the post set up better than before, so that is a good thing.

I've also changed my habits with regards to the initial Rapid plane and tool offset. I developed perhaps an erronous habit of running my Z home at Z0.1 , my tool length offsets all the way down to Z0.1 and Rapiding around at Z.1 (My one mill has fairly limited 4.5 inch Z axis travel).

Instead, now I define a Z home of Z1.0, define the length offsets relative to Z1. and Rapid around at Z1. This allows me to call the tool length offset without worrying about the tool being so near the surface, and allows a little more leeway for error, should an offset happen to be slightly incorrect when it is called (the tool moves when the offset is read). This change allows me to make better use of the intermediate positions that Onecnc allows for in positioning the tool before the plunge, etc.

Say, we were agreeable on the potential benefits of a"peck-plunge" option when using end mills, what do you think about the option for Rapid plunge, as well?

I find there are times when I do start a multi-pass roughing cycle with the tool "out in the air", and this gets fairly tedious to watch the thing plunging at a typical feedrate. In the meantime, when I foresee such circumstances, I am happy enough to insert a very high plunge feedrate to accomplish the same thing as rapid, but it doesn't seem to me to be as clear to the operator as a Rapid command would, when he's checking through the code on the machine display.

Originally posted by wms
Hu,
I miss spoke in the above post. The extra boxes are under the G83 cycle not the G81. Shame on me.:o

You do realize that these extra boxes appear when you create a new parameter, right? Just testing your knowledge, this was not immediately apparent to me, either.

Hu,
I just use the Haas post and don't need to create any new parameters.....Yet.
So I kind of knew that "STUFF" would show up in the boxes after you create new parameters. Mostly after "looking" at your shadow cfg.
I feel for you because you have to make up your own posts.:p
I'm spoiled in that the standard posts, so far, do every thing I need them to. Maybe I'll get creative like you and add some extra features.

Pretty neat that you can modify your post so easy in OneCNC, don't ya think?


And as far as the Rapid Plunge thing, I'm all for more features. Any thing to make my life easier.

Oh by the way... Stop testing Me....:D:D:D

Originally posted by wms
snip
Pretty neat that you can modify your post so easy in OneCNC, don't ya think?


Absolutely! I spent hundreds of hours learning about and making scripts in Bobcad to do what Onecnc can do "out of the box".

I suppose there is not enough user base here to get a decent poll result, but I would still like to know if the cycle "initial plane" and "retract plane" is perfect as set up.

I can see the need for a couple of different options, depending on what your controller expects. The options I am referring to are simply this: should these two planes be absolute values or incremental? Should the values be operated on mathematically or just "left alone" so to speak.

I do have sort of a system to make the resultant output come out right.

Here is what I have figured so far. Here is what I have set up in my deep hole peck cycle:

/Z{CD} Z{_PECK} /Z{_RETURNSTOP} /R{CP} /T{_DWELL} G83
/Z{_P8}

Here is how I might want a sample of code to look, where the initial plane is equal to the Rapid plane:

T4 ( 3/32 DRILL)
F12.5
S70 M3
T400
M8
/X2.6734 /Y-13.1875 /Z1. (Rapid plane absolute)
(if initial plane <> rapid plane then a value appears here)
/Z-1.2 Z-0.4 /Z-0.01 /R0.2 /T0. G83
/Z0.2 (this is the move to the initial plane, absolute in value, the cycle begins to execute at Z0.2)
/X3.1855
/X3.6976

In the above sequence the tool rapids from Z1 to Z.2, then rapids from Z.2 by the incremental distance indicated by the /R value, which brings the tool tip right to Z0. Then the drill drills an incremental Z-1.2, with a peck distance of -.4.

A chipbreak move is indicated by the /Z-0.01, which I created the variable {_RETURNSTOP} to hold. This is fine.

If the initial plane is equal to the Rapid plane, then no nc output results between the initial Rapid height and the calling of the cycle. This is okay by me.

Whatever I put into the Retract plane field is apparently subtracted from the initial plane to equal the net retract height that is output. This seems weird to me. I'd just as soon be able to type in what I want it to be in absolute, and have that exact same figure come out in my code.

For my controller, the R value is an incremental distance, that the tool will traverse (at rapid) at the start of every hole in the cycle. The end of every single cycle results in a retraction back up to where the tool started the cycle at.

Suppose Rapid height is 1", initial plane is .2" absolute and retract plane is .2" absolute. In order to make the right code, I have to enter values in the initial and retract fields that give a subtrahend of 0.2 . Thus, I would put in .2 in the initial field and 0 in the retract field. This results in nc output of .2 for the value /R{CP}. note the retract plane value of 0 is meaningless so far as where I intend to begin the tool at, which would have to be at a value of R.2

Because some kind of subtraction also seems to be performed on the initial plane variable {CP}, I cannot use it either, so instead I created this new parameter /Z{_P8}.

This is not whining. I am just wondering if there needs to be more of a "setup" to the nature of these Initial plane and Retract plane variables, depending on what various controllers require.

Perhaps it is all in the method I am thinking in, but it seems to me that the rest of the toolpath wizards operate on the principle that the various tool planes are absolute Z values, but when we get into the cycles, then all of a sudden, they switch to relative values.

I am sorry if I am not making this perfectly clear. But, you would know by now perhaps if you had any difficulty making the right input when you fill in the fields in the cycle wizard, using your own machine's cycles.

Just to test your own cycle setup, does what you have also work if you want to drill a hole at a lower level, like Z-1. down to Z-2., but maintaining your retract height at Z.2 between holes?

Maybe they should add the words "relative or incremental distance" to the Initial and Rapid planes in the cycles?

Opinions? Discussion?

HU,

Here is a sample post. This is with the Haas cfg. Xpert program.
At the bottom is a screen shot of the setup box.
Seems to work just like it should. Sorry.:P
All figures are absolute. No addition or subtaction was done by the program.

%
O0000 (PART - )
(POSTED - FRIDAY, MAY 30, 2003 (19:03))
T1M06 (1.0 INCH HSS 1.0 DRILL)
G90 G80 G40 G55
S1505 M03
G00 X0. Y-0.6172 / M8 ( move to position)
G43 Z1. H1 (call tool height offset, also rapid plane)
Z0.2 (move to initial plane)
G81 Z-2. R-1. F5.7189 (drill cycle -1. is retract plane)
Y-3.3828
X-4.
Y-0.6172
G80
G00 Z1. (back to rapid plane)
M01
M30
%

Ok, I've changed my G83 slightly and improved it quite a bit so that I don't see the confusion that I had before.

/{Z} Z{_PECK} /Z{_RETURNSTOP} /R{CT} /T{_DWELL} G83
/Z{_P8}

However, there is the one issue. WMS, what would you do to your post if you wanted to call the initial plane after your G83 line? As things stand now, the initial plane is automatically inserted before the cycle start lines are written. My controller actually needs this value inserted after the G83 line.

The initial plane is supposed to be parameter {CP}, but if you place it after the G83 line, you no longer get the actual value that you put in the initial plane field. This is what seems strange to me, the way this value changes. See, in my case, although the move to the initial plane is always written before the G83 line, this does no harm, but really, I need to have exactly the same initial plane figure written after the G83 line.

Try adding that /Z{CP} parameter after your G83 and see if you can find a way to get the initial plane value to transfer into that spot, using the stock selection of variables available. It seems to me that we should be able to, but I cannot figure out how to do it without creating my own new variable.

Hu,
I'm working on a cfg file right now for you I think I'm close.
Take a look at the Haas cfg G83, You will see that there is no {cp) in it.
So it must get that info from the setup box when you select your setting at "tool" time.
Also I can get everything you want except the {_returnstop}
Clue me in on how you did that, old buddy!
Also do you need the / at all the z calls on the g83 line?
Just wondering, (I do that alot)

You are right about the {CP} and I studied your Haas post a little more closely, and saw that I could also get the commanded drill depth with a simple {Z}, whereas, I was using {CD} before. Guess I was reading too much into the variable names. :)

I simply created a new variable called RETURNSTOP. Initially, when you create a new variable, it will be given a number name, but you can simply rename it to a meaningful name as you desire.

The / must appear as shown, but they can simply be slipped in front of any Z that needs it when you are composing the line in the start lines field. The / indicates a Rapid movement, without the slash, the movement will be feedrate.

/Z-1. Z-.1 /Z-.01 /R .1 /T.2 G83

Means:

/Z-1. = total (incremental) depth of -1, with rapid returns

Z-.1 = peck increment, obviously at feed rate (no slash)

/Z-.01 = rapid withdraw right out of the hole to the retract height, with rapid return stopping .01 from the bottom of the last peck. If this value is positive, the move is a simple chip break, only moving up .01 and then back down. No / would be a feedrate chip break movement, not normally desired as it is too slow, and would serve no purpose. (I understand that a lot of controllers have this parameter built in as a system parameter, which makes sense because I always use the same value, it is just the sign that I might alter, depending on the depth of the hole).

/R = retract height. This is the incremental distance that the tool will rapid down at the start of the hole drilling action. It must always be positive. I think the manufacturer of my control must have goofed up the firmware, because the book reads like this should always be negative, but that doesn't work right.

/T = dwell in seconds, resolution .01

Normally, the /R value and the initial plane would always be identical if drilling starts at Z0. This seems confusing, but the initial plane must be at Z.1 if R = .1 because the tool will rapid down by the amount of the R value. Naturally, there are other times, when I want the R value to take the tool at Rapid below Z0 in the situation where I am drilling a stepped hole. Say the bottom of the previously drilled hole was at Z-.5, and I want to drill deeper with different tool in a different cycle. Then I would use an initial plane of Z.1, but an R = .6 to get the new tool to rapid all the way down to the bottom of the previous hole to start drilling.

Originally posted by HuFlungDung
I simply created a new variable called RETURNSTOP. Initially, when you create a new variable, it will be given a number name, but you can simply rename it to a meaningful name as you desire.
[/B]

Hu, It must be late because I don't get the create new variable.

Anyway:
(you fill in the blanks)
Here is the nc file (pretty close)
%
O0000 (PART - )
(POSTED - FRIDAY, MAY 30, 2003 (22:00))
T4(.0938 INCH HSS 3/32 DRILL)
F4.32
S70 M03
T400
M8
/X0. /Y-0.6172 /Z1.
/ / /Z0.2
/Z-1.2 Z-0.4 /Z{_RETURNSTOP} /R0.2 /T0. G83
/Z0.2
/ /Y-3.3828
/X-4. /
/ /Y-0.6172
/ / /Z1.
M01
M30
%

And here are the settings

second setting

I'll e-mail you the cfg file and you can see.

Originally posted by HuFlungDung
I simply created a new variable called RETURNSTOP. Initially, when you create a new variable, it will be given a number name, but you can simply rename it to a meaningful name as you desire.
Originally posted by WMS
Hu, It must be late because I don't get the create new variable

DUH, Would that be the ADD button right in front of my face?:withstupi (should read I'm AM stupid)
Going to bed now, have to rest.:tired:

Hi Ward,

Thank you for your effort. This is what you ended up with:

{_MODE} /{Z} Z{_PECK} /Z{_RETURNSTOP} /R{CT} /{_DWELL} G83
/Z{CT}

This works okay so long as I am always drilling a surface that starts at Z0, because the initial plane can equal the retract plane. However, there are other times when this will not work, and the Initial plane needs to be different than {CT}.

I'm happy enought with what I have now, I am considerably less confused. I do still wonder why the variable {CP} does change value from what is input though.

HU,
Forgive me but I must be missing something(again).
I set:
rapid plane 1.0
Initial plane .5
Retract plane .2
Final depth -1.2

And here's the code:

%
O0000 (PART - )
(POSTED - SATURDAY, MAY 31, 2003 (11:35))
T4(.0938 INCH HSS 3/32 DRILL)
F4.32
S70 M03
T400
M8
/X0. /Y-0.6172 /Z1.
/ / /Z0.5
/Z-1.2 Z-0.4 /Z-0.01 /R0.2 /T0. G83
/Z0.2
/ /Y-3.3828
/X-4. /
/ /Y-0.6172
/ / /Z1.
M01
M30
%


As you can see there is no change in the code as far as what was input.
Clue me in, what am I missing?

That is right there is no change because you are using {CT} in both places, but you also are not getting the same initial plane value twice, you are getting the retract plane value twice, where I am saying that there are instances where the value of R is going to be different than the initial plane move that follows on the next line.

If I want to drill on a surface that starts at Z-.5 then I need the code to read like this

/X0. /Y-0.6172 /Z1.
/Z0.5 (initial plane)
/Z-1.2 Z-0.4 /Z-0.01 /R1. /T0. G83
/Z0.5 (same initial plane) <--this is the output that you cannot make match the initial plane.

You cannot get the proper output for this last line by using {CT} again, and I think that I should be able to get it by using {CP} because that is supposed to be the initial plane. However, try it, and you will see that you cannot get the same value out of {CP} as you get when you enter a value into the initial plane field.

HU,
I misunder stood what you wanted by your earlier post

/X2.6734 /Y-13.1875 /Z1. (Rapid plane absolute)
(if initial plane <> rapid plane then a value appears here)
/Z-1.2 Z-0.4 /Z-0.01 /R0.2 /T0. G83
/Z0.2 (this is the move to the initial plane, absolute in value, the cycle begins to execute at Z0.2)
/X3.1855
/X3.6976

Here both R and Z are 0.2 s at line g83 and below.

I know what you mean about the{CP} subracting the one from the other. Not right.

In the example below I add a variable {_Initial plane2}
below the G83 line(this is the same thing you did with your {_P8}
Now we have Initial plane above G83 and below.


%
O0000 (PART - )
(POSTED - SATURDAY, MAY 31, 2003 (12:30))
T4(.0938 INCH HSS 3/32 DRILL)
F4.32
S70 M03
T400
M8
/X0. /Y-0.6172 /Z1.
/ / /Z0.2
/Z-1.2 Z-0.4 /Z-0.01 /R-0.5 /T0. G83
/Z0.2
/ /Y-3.3828
/X-4. /
/ /Y-0.6172
/ / /Z1.
M01
M30
%

So after we understood each other and after all this we agree that the {CP} should do what you need , but it does not.
I stand corrected.:o

But it looks like adding this extra variable will ge the job done. And you go to that setup box to add other info so, not to bad.

We could have come to this conclution in 2 minutes had we been in the same room, then you could have just hit me in the head and straightened me out.:D

Thanks for your input and for being a sounding board, Ward.

At least I now have a formula that is giving me the right output that makes sense to me from the input I was giving. Now, I just have to "unlearn" my previous faulty method and I'll be set :)

For those who may still be reading this thread anew to try to accomplish the peculiar requirements of your controller whilst using your own machine cycles, I did find today that although I have gotten very workable custom drill cycles set up in OnecncXP, I wasn't getting an accurate rendering of the procedure when doing the simulations.

This is due to my Shadow (Bandit1 style) controller mixing together the incremental with the absolute, ie., the parameters within the G8x cycles are deemed to be incremental amounts, even when the main program is absolute without switching to G91 mode and back again.

Onecnc is assuming absolute coordinates are used throughout, I believe. Previously, I was trying to use some of the parameters that you see in the initial "Set clearances" dialog in the drill cycle but, if you use a mixture of incremental and absolute values in this dialog, then you end up with incorrect parameters for the simulations, even though your code may be correct.

Therefore, I decided to create all my cycle parameters anew in the "cycles" dialog in nc setup, even though there is often some redundancy to doing this.

By doing this, I can if I wish, start drilling at a plane below Z0, and still get perfect code and a correct simulation at the same time.

The short of it is this: whatever you input into the clearances dialog pertains to how correct the simulation of the cycle will turn out, but whatever parameters you create for the next "Cycles" dialog affects how your nc code turns out, but does not affect the simulation.

If you are blessed to operate a controller that doesn't require that you jump through any hoops, or if you are using Onecnc's built in cycles, then you can safely ignore this :)

The set clearances dialog

Here's how my cycles dialog looks with my own parameters