G65

[JSaindon]

We have an old Allen Bradley 9/240 control on a grinder and it seems to hang up after the dressing subprogram with coolant still on. It seems that the G65 paramacro was the culprit, I just was not sure why. Here is the program in question.

(XO96L PLUNGE GRIND)
G65P993
#500=58 (Position of pocket to cut)
G65P9302C2D0F10I1.0J.125K1.2R2.0S105U0W0X0Y-.100Z.0000 (Cut Part)
G65P901A90D.003E07M0R2S70U1V1 (Dress Roll)
M9 (Coolant Off)
G65P994 (Return to Load Position)
M30

Since the machine came up with no alarms, I wanted to dig into the programming and check for any redundancies and errors. I noticed the G65P994 was in all of the programs that would "hang up". Here is what I read about the G65.

The key difference between a subprogram and a G65 paramacro is that a paramacro always gets a new set of local parameters; a subprogram uses the same set of local parameters that the main program used. The G65 command is non-modal. The macro is executed only at the time the control executes the G65 block. The control calls the macro specified by the G65 block as programmed by the P word.

Once I removed G65 and just used the P994 call, the program hasn't hung up yet. From what I read about it I don't see why it would matter if it were in there or not. All P994 does is move the table to the loading position. If anyone knows more about the G65 or modal/non-modal paramacros, could you explain maybe in more general terms what these are and if the G65 is necessary in my case? I could post the P994 program also if needed.

[psychomill]

I'm not sure on a A-B control, but the G65 in your program (for other controls) is a macro sub call to program number 994. If I were to guess, your program 994 has a problem with it and that's the hangup. If you strip the G65 and you're not hanging up, I'd say that the control is just simply blowing past through the "P994" line. Essentially ignoring it. You could post your 994 program. Maybe we'll see something wrong there....

[JSaindon]

Here is the P994 program. The table does go back to the loading position though.

O00994(TO LOADING POSITION)
(25-NOV-1993)
#2101=#5508/2
#5321=0,#5322=0,#5323=0
T1
G1G59G61G90Y#545F0
M09M79T0
X#544Z#546
M99

[JSaindon]

The program actually hangs up in the P901 program though. At least that is the line of code that is displayed on the screen when it hangs up. Unless the actual line of code the control hangs up on would be passed the one displayed, I'm not sure of this.

Would the program not execute the P994 without a paramacro call before it? Couldn't I just use M98 to call the subprogram?

When a G65 is executed, where does the new set of local parameters come from? If the parameter was altered in the main program, is there a backup of that parameter that gets loaded to the original value when the G65 is executed? I got confused at the manual's explanation.

If P994 is being skipped why would the table go back to the load position then? So many questions I cannot find the answers to. The programming manual alone doesn't explain enough for me to grasp what is going on in my situation. Knowing only what I read in the manual doesn't help much either.

[psychomill]

Any "Look Ahead" on the control may confuse the issue as well. If you can, what you'll want to do is bump through the program in single block mode. This way, when the machine reaches the line with the problem, it will stop on that line. When a machine has any look ahead, its possible to "bomb out" before it actually gets to the line with the problem... especially if its contained within a macro sub or standard subs.

Normally, a P address by itself will not jump to a sub unless it has a G65, G66, M98, .. or any other sub call commands. Some machines can be set up differently though. Yours may jump to the P address but it may have limited functions in the way its handled (as a simple M98 for example) so you'll have to go over the books on that.

For G65, the "parameters" or variables gets loaded from that line of the call. Something like this:

G65P8855E12.R.005

In this line, it will set the variable for E (#8) to 12. and "R" (#18) to .005 .

If the parameter was altered in the main program, is there a backup of that parameter that gets loaded to the original value when the G65 is executed?

Uh... yes and no. What you would need to get into here is called Nesting. This is how you can change levels of the macro to utilize new values while retaining previous values or commands. That's another story though and for the time being, you may want to remain concentrated to simple or single level programming.

Couldn't I just use M98 to call the subprogram?

In your post of the the 994 program call, Yes. You could do the same thing with M98. But, in the same program where it calls "P9302" and "P901"... No. You'll see those lines are also setting values to variables (A, C, D, I, J, K, etc). M98 is simple sub call and doesn't allow for variables. Since the "994" call isn't setting any variables, you could use M98.

[JSaindon]

Thanks for clearing some of my questions up. I now understand clearly how the paramacros are called. Since this is/was an intermittent problem and not really a high priority I won't bother running in steps. I don't need the P994 in there anyway since the table goes back to home anyway. With P994 in there it goes to a slightly different position, so I will just leave it out and it is not an issue. The control doesn't hang up anymore either.

One last thing though about the "look ahead". I am aware of this on these controls, and I was assuming that means that the actual line of code the control is on would be after the line displayed on the monitor correct? So P994 could be the issue since the #1000 comparison is at the end of P901.

Either way, the control works, this just has been bugging me. Thanks again for the input.

[psychomill]

I think you're on the right track about look ahead. Basically, its this: Often the look ahead function may stop the control if it detects an error. But physically, your machine may not have reached that point yet. For example:

X-1.Y13.
G1Z-.5F100.
X2.
G0Z.25
X14.
M98P200
.
.
.
O200(SUB 200)
X.6Y-1.
X1.5I-1.5J.875
G1X...
.
.

In the above example, control may appear to stop at the line "M98P200" or possibly one or two lines before it. In reality, the error is in the sub at the line with the arc motion (I and J) because you don't have a G2 or G3 for it. This isn't just a sub routine thing either, it can often happen in root programs as well.

HTH

[JSaindon]

I got you. From what I see all the programs seem fine though. I just changed the sub call to M98 and no issues since. I don't know why the programmer put that return to home P994 program in there, the machine goes back to just about the same spot without it. It seems like when the machine finishes the program it goes back to the start position, so P994 is pretty much redundant in my case. Hey, "if it works don't fix it" applies here. Thanks for clearing up some questions I had though. Much appreciated.

[psychomill]

One thing to think about... the call line might have been there as a safety line or safety move to retract for things like tool changing, wheel dressing, end of program... a number of things. Maybe a variable in the program got wiped out by accident or code edited mistakenly.

[Andre' B]

I can't say I know anything about this control but, I see a line in that 994 sub with a G1 move at a feed of zero.

[psychomill]

I missed that.... duh


I think you're right....

[sinha_nsit]

Originally Posted by psychomill I think you're on the right track about look ahead. Basically, its this: Often the look ahead function may stop the control if it detects an error. But physically, your machine may not have reached that point yet. For example: X-1.Y13. G1Z-.5F100. X2. G0Z.25 X14. M98P200 . . . O200(SUB 200) X.6Y-1. X1.5I-1.5J.875 G1X... . . In the above example, control may appear to stop at the line "M98P200" or possibly one or two lines before it. In reality, the error is in the sub at the line with the arc motion (I and J) because you don't have a G2 or G3 for it. This isn't just a sub routine thing either, it can often happen in root programs as well. HTH

I am under the following impression about look-ahead:
1. For a program without radius compensation and without macro statements: One block.
2. For a program with radius compensation but without macro statements: Two blocks.
3. For a program with macro statements: Several blocks of consecutive macro statements.
This is the reason why, in the radius compensation mode, if two consecutive non-motion blocks are specified, the tool does not position it properly at the start of the next line (or arc), because it does not "see" this line (or arc) while executing the previous line (or arc).
I am not an expert, though I have a habit of reading and analyzing. So, please correct me if I am wrong. Thanks.