[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]

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):tired:

[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.

[stevo1]

Sinha,
That is crazy I will have to try that and see if I can set #1 by using #0.5. I would think you would just get an “illegal” variable alarm or something along those lines.

I agree with you I now use rounding on every variable were it can be less than 1.0. However as I stated in the other thread were you and I discussed this I have never had to do that before. I had programmed many complex macros were the control had never given a .499999 in place of .5. It always was what you programmed.

Stevo

[sinha_nsit]

There are crazier things (at least on 0i Mate):

If #1 = 1000.5; then S#1 is equivalent to S1001, but S1000.5 (and even S1000.0) would be illegal, because the S-value must be an integer (though a parameter setting accepts up to one place after decimal).

If #2 = 2.5; then M#2 is equivalent to M03

M3.0 is illegal, but M[3.0] is equivalent to M03

G-code is less liberal (allowing an "error" of less than 0.05, possibly because some G-codes use one place after decimal such as G13.1). So,
if
#1 = 1.9499999;
#2 = 1.95;
#3 = 2.0;
#4 = 2.0499999;
#5 = 2.05;

then
G#1; (Illegal)
G#2; (Equivalent to G02)
G#3; (Equivalent to G02)
G#4; (Equivalent to G02)
G#5; (Illegal)

Finally,
G[01] is not equivalent to G01, and, in fact, it is illegal.
G[03] is not illegal, but it is not equivalent to G03, and causes unexpected tool movement in rapid traverse mode (so do not try it!).

I have verified all these things on 0i Mate TC. It would be interesting to know the response of other control versions.

Custom Macro B should have been more "disciplined".

[James L]

I use a HAAS control and it will not accept #.5=10;. Says that it is a bad code. From what I understand, macro b has to be tailored from control to control. Macro variables are supposed to be a positive number with no decimals so, where some machines will round this value, others will not accept it.

[sinha_nsit]

I use a HAAS control and it will not accept #.5=10;. Says that it is a bad code.

Try this also, and let us know the result:
#1 = 0.5;
#[#1] = 10;
Is it still illegal, or sets #1 = 10?

[James L]

Gives an illegal variable assignment error. Basically the same as before. When i tried to enter #.5=10 before, the control wouldn't even let me insert that line. Using what you recommended, I can enter the code but cycle start brings up the new error.

[sinha_nsit]

Gives an illegal variable assignment error. Basically the same as before. When i tried to enter #.5=10 before, the control wouldn't even let me insert that line. Using what you recommended, I can enter the code but cycle start brings up the new error.

That is the way the control should behave.
And we believe that Fanuc is the best!

[John_B]

Motor,

So have you made any parts yet? Which method did you go with? Any feedback?

John

[MOtorPARts]

Motor,

So have you made any parts yet? Which method did you go with? Any feedback?

John

no- not yet, i won't be back to work till a week from today, i started this thread while i was laid off so i had time to study & soak in all the info before i start messing around. i did make one "prototype" but i was babysitting the machine dropping the z offset by .015" after every cycle, till i got to .180". this is a govt' job that i have permission to work on during my lunch, so i want it to run as efficently as possible.