fanuc o-m, subprogram repeat w/ z axis shift?

[MOtorPARts]

hello all- newbie here, i've done some searching, but couldn't find any info. i run a late '80's kiwa 510 colt VMC with series o-m controller. i am trying to repeat sub program o3450 12 times (m98p123450), but each time it repeats i want the z value in the work offset to change by an additional .015" . is this possible? if so how?
thanks for any help-jeff

[John_B]

You can use incremental positioning, G91, in the sub-program.

Just move the table to the location you need to start in G90 mode before jumping to the sub, then begin using incremental mode. You can make all moves in incremental, or just the Z, you just have to be careful to change back and forth.

[dcoupar]

Well, here's a couple of ideas.

If your control has the G10 option, you can use G10 G91 L2 Pn Z-0.015 (Pn is P1 for G54, P2 for G55, etc to P6 for G59).

O1001 (SUB PROGRAM)
(INCREMENT G54 Z-0.015)
G10 G91 L2 P1 Z-0.015
G01 G90 Z... F20.
X...
...
M99

When you're all done don't forget to increment it back up 12 * 0.015:

G10 G91 L2 P1 Z0.18

- or -

If you have User Macros you could write a macro to do it.

[sinha_nsit]

Originally Posted by dcoupar If you have User Macros you could write a macro to do it.

For example, insert #5223 = #5223 - 0.015 in the beginning of the subprogram, on 0i control.
After the M98 block, insert #5223 = #5223 + 0.18

[James L]

some variation of this might also work
program -
.........
#33=12;
#32=#5223;
while [#33 gt 0] do1;
m98 p#;
#5223 = #5223 -.015;
#33 = #33-1;
end1;
#5223=#32;
.........
program -

this way you can keep the macro in your main program

[James L]

Just out of curiosity.. why do you want to change the offset to do this? It will work, but I do try to avoid altering offsets as much as possible. If you are repeating a pattern over and over with a simple z step with each pass, I believe using an incremental step at the start of your sub-program should be effective.

[MOtorPARts]

it dosent have to be in the offset, it was just my way of saying everything pertaining to the z axis, sorry for the confusion, so would you recommend somthing like dcoupar posted? i won't be able to fart around with these ideas till i return to work on the 14th(laid off till then)

[James L]

Dcoupar or john b's suggestion earlier are both methods that would do what you need. I would personally do as much as I could without altering work offsets.

[stevo1]

Altering the work offsets if you are changing the total part height say surfacing then I don’t see an issue with changing the work offsets because you are adjusting them to match what you physically have.

I also agree with James that if you are doing a feature that is not changing the physical height of the part then I would go about using a loop and a variable to move the Z down. You will need macroB programming on the control. You can do a WHILE statement as James suggested but use a variable instead of the work offset.

O0001(main program)
M98P3450
M30

O3450(subprogram)
#1=0-----------incremental Z (set to .015 if you want to start off being .015 deep in the part otherwise leave at 0)
N1
G0X()Y()Z-#1---start position at a Z of the value of #1 which is 0
…-------------your code here
#1=#1+.015---once first pass is complete it will add .015 to variable #1
IF[#1GT.18]GOTO500---if you reached .18 deep then it willgo to N500 and end subprogram if not it continues to next block
GOTO1---will jump to N1 with the new #1 value which will be .015 more.
N500M99

Stevo

[sinha_nsit]

Incidently, the manual recommends the use of WHILE_DO_END loop over IF_GOTO_ statement, as the WHILE loop is faster. In fact, I have tested this. I wrote two macros for clearing permanent common variables #500 - #999, using the two methods. The WHILE loop method takes nearly half the time (about 5 seconds, which was 10 seconds with GOTO method, on 0i Mate TC).

There can be one more issue, though not in this case.
The macro calculations are not extremely accurate. So, if a lot of complex calculations are involved, there is a possibility that the expected 0.18 may actually appear as 0.1800001 or 0.1799999. This may affect the logic in comparison statements. Someone of you might have faced this problem in the past. In such cases, instead of #1, one may use
[ROUND[#1 * 100] / 100]

[stevo1]

Sinha,
I agree with you the WHILE statements are faster. I prefer to do it that way as well. The other reason that it is recommended to use the WHILE over the GOTO is because you can lose track in an extensive program with too many GOTO statements were it will jump to the wrong sequence. Downside is you can only nest 3 WHILE statements and they can get confusing if you have 3 nested and are running multiple subprograms. I usually end up using both actions, the WHILE for the continuous machining and the IFstatments for calculation and variable changing.

Yes the rounding function can burn you. I have been burned by it before. Motors application would be a good time to use the "round" function given the pick size is .015 (good catch). Sinha we had discussed this in a previous thread, if anyone is interested here is a thread that I started posing the question of the “floating point math”.

http://www.cnczone.com/forums/showth...ighlight=round

Stevo

[sinha_nsit]

Stevo,
Rounding is the only way to handle this situation, as suggested by you.

Just for the sake of having some fun, the control also does "implicit" rounding, in some cases. For example, if you command #0.5 = 10, it will assign the value 10 to #1 (I have verified this on 0i Mate).
On the other hand, #.49999999 = 10 would be an illegal command, because #0 is a read-only variable!
There are several other interesting cases.
All I can say is, one has to understand the internal logic of the control. And such things are not discussed in manuals. One learns only after facing some peculier problem.