Canned cycle drilling quarks

[ny_winemaker]

Good evening all, I have been trying to get an old version 9 Bridgeport dx32 post to work with X5. I have everything good until it posts the canned drill cycles. I am setting depth$ = abs(depth$) and when I watch the value in the debugger it is giving me a positive value every time. When it writes to the nc file the first drill cycle will have a positive z value and the next G8? call the z value will be negative, even though the watch window says it should be positive. Then I might get a depth value that is .1875 smaller than it should be. Again with the value in the watch window being what it should be. Then it will go back and post the next call correctly. There dosn't seem to be any constincy in what it's doing. It also doesn't matter what canned cycle I use as it is doing the same with all.

 

If anyone can help I gladly appreacate it. I have been pulling my hair out as it doesn't make logical sence as to what is going on. I would copy some of the post and output but I'm writing this at home and don't have the post here. If that is needed I can include it tomorrow when I get to work.

 

James

[Bryan Johnson]

there may be another depth call in pdrill_2 that is causing your trouble.

I also show that for this control, you need to consider the reference height in your depth calculations.

 

Below is the drilling post blocks from a post that i setup.

I can send you a copy of this if you need a better example.

 

 

 

incdrdp = abs(refht$ - depth$) # For Incremental drill depths

 

 

p_jump # Cancel cycle a move to initht befor going to next hole

n$, "G80", e$

n$, psg00, *initht$, e$

n$, *x$, *y$, e$

 

pdrill$ # Canned Drill Cycle

if refht$ <> initht$, n$, *refht$,e$

n$, *sgdrill, *x$, *y$, *incdrdp, *frplunge$,e$

 

ppeck$ # Canned Peck Drill Cycle

if refht$ <> initht$, n$, *refht$,e$

n$, *sgdrill, *x$, *y$, *incdrdp, *peck1$, *frplunge$,e$

 

pchpbrk$ # Canned Chip Break Cycle

if refht$ <> initht$, n$, *refht$,e$

n$, *sgdrill, *x$, *y$, *incdrdp, *peck1$, *frplunge$,e$

 

ptap$ # Canned Tap Cycle

if refht$ <> initht$, n$, *refht$,e$

n$, *sgdrill, *x$, *y$, *incdrdp, *frplunge$,e$

 

pbore1$ # Canned Bore #1 Cycle

pdrill$

 

pbore2$ # Canned Bore #2 Cycle

pdrill$

 

pmisc1$ # Canned Misc #1 Cycle (Rigid Tapping)

n$, "M29",e$

if refht$ <> initht$, n$, *refht$,e$

n$, *sgdrill, *x$, *y$, *incdrdp, *frplunge$,e$

rigid = 1

 

pmisc2$ # Canned Misc #2 Cycle (User Option)

pdrill$

 

pdrill_2$ # Canned Drill Cycle

if refht$ <> initht$, p_jump

if refht$ <> initht$, pdrill$

if refht$ = initht$, n$, x$, y$,e$

[ny_winemaker]

Thanks for the reply.

 

We have had this machine for years and have been and are still using FeatureCam for most of the programming. We have some Thermwood routers and Robots that I have been using Mastercam with. The workload for the CNC's increases at time that I want to be able to help out. I have used the FeatureCam but I prefer Mastercam and I haven't really used the other for the last couple years.

 

That being said I am trying to make the nc file from mastercam look the same so the operators don't have to try to figure out what is happining. The posting from the featurecam doesn't include the differance from the inital height. Also there isn't anywhere that the depth$ gets changed execpt when it is read from the NCI. As I said what is output isn't the same as what is the current value in the watch window. I am using the debugger in MC to step through the programto watch what is going on. This is very perplexing as to why it isn't outputting what is in the watch window.

 

I will try your code tomorrow to see if it takes care of the problem.

 

Thank you again.

[ny_winemaker]

Why don't I get the same values on variables each time they are used?

 

I'm looking at the drilling cycles and the depth$ doesn't equal the value in the MC file for every drill call. Sometimes it is correct then the next call it will be way off. Also after printing a variable it is cleared to zereo. This is happining with variables I declare as well as the depth$ from the NCI file. I have tried to force a read but it doesn't work. I'm using X5 by the way.

 

N20G0X0.Y0.T2M06

N30S3667M03

N40G0X-2.3669Y-1.323

N50G0Z1.

incdrdp = abs(refht$ - depth$) in pdrill0$ ONLY

N60G0Z.25

 

rtnrefht$ variable : P0.

refht$ variable : Z.25

initht$ variable : Z1.

zdrl$ variable : P0.

depth$ variable : Z-.125

znci$ variable : P-.125

 

.N70G81Z.375F7.3 (without outputting the incdrdp variable it showes in gcode)

'.' n$, *sgdrill, *incdrdp, *frplunge$

N80X-2.3669Y-1.323

incdrdp = abs(refht$ - depth$) in pdrill0$ ONLY

 

incdrdp variable : Z0.

rtnrefht$ variable : P0.

refht$ variable : Z.25

initht$ variable : Z1.

zdrl$ variable : P0.

depth$ variable : Z0.

znci$ variable : P-.125

 

N90X-2.334Y1.424

n$, x$, y$

N290G80

 

N310X0.Y0.T3M6

N320S4561M03

N330G0X-.9803Y.5828

N340G0Z1.

incdrdp = abs(refht$ - depth$) in pdrill0$ ONLY

N350G0Z.25

 

incdrdp variable : Z.75

rtnrefht$ variable : P0.

refht$ variable : Z.25

initht$ variable : Z1.

zdrl$ variable : P0.

depth$ variable : Z-.75 (depth$ here should be Z-.875 as it is in the MCX file)

znci$ variable : P-.875

 

.N360G83Z0.Z.1Z.1F43.8 (After printing the incdrdp in the line above it becomes 0. here)

'.' n$, *sgdrill, *incdrdp, *peck1$, *peck2$, *frplunge$

N370X-.9803Y.5828

incdrdp = abs(refht$ - depth$) in pdrill0$ ONLY

 

incdrdp variable : Z0.

rtnrefht$ variable : P0.

refht$ variable : Z.25

initht$ variable : Z1.

zdrl$ variable : P0.

depth$ variable : Z0.

znci$ variable : P-.875

 

N380X.3603Y.8851

n$, x$, y$

N390G80

 

I'm not changing the depth$ anywhere just reading it and using it in the formula above.

 

Any help?

 

I can send the file if needed.

[Colin Gilchrist]

James,

 

Any variable that ends with a Dollar Sign '$' is a pre-defined variable. Pre-defined variables have their values set automatically, based on information in the NCI file. So it is possible that 'depth$' is getting overwritten by MP.

 

I would recommend creating a user-defined variable, and trying that in your Post.

 

The other variable you could capture the value from is 'znci$'. During a Drilling Cycle, that variable holds the same value as 'depth$'.

 

When making edits for Canned Cycles, are you aware of the post structure for Drilling?

 

For the First point in a Drill Toolpath, the post will call an entry post block, based on the type of drill cycle. For 'drillcyc$ = 0', you will get a call to 'pdrill$'. If 'drillcyc$ = 1', the post would call 'ppeck$', and so on. This is the call for the first point only.

 

Additional drill points are output with separate post block. For example, with 'drillcyc$ = 0', the second (and all other) points in the toolpath would call 'pdrill_2$'.

 

Just wanted to mention that in case you weren't aware.

 

Also, the Post Block 'pdrlcommonb' is called prior to all drilling post blocks. This 'Common call before' block is used to make global settings prior to outputting the Canned Cycle code. It's always possible that you have some code in 'pdrlcommonb' that is stepping on your 'depth$' variable.

[ny_winemaker]

Well I figured it out sort of. Still not compleatly sure what happend, but it works and that's the best thing. I'll keep digging into it and someday I'll find out why it did what it did.

I had the variables formated as "fs 9 1.4i" and it seems that with that formatting the variable getts cleared any time it is used in any kind of out put statment. After many tries and reading the post manuals I thought I would try a different format for my variables and low & behold it worked. Thanks to all who offered help and I hope someone reading this is helped by my mistake.

 

4:15 pm

I just found what is happining. In the version 9.1 MP Post Referance guide Vol.1 chapter 9 page 7 it says " Incremental output is calculated in the post excutable as the differance from the previous move to the current move. You should use incremental carefully becaues, at the moment after the NC output occures, the value is zeroed.

 

So I guess I should have done a little more reading before choosing to use incremental.