Toolsetting macro on 0m-C

[John_B]

Can anyone help me understand why my old machine (1990) with the 0m-C control is balking at the T code shown below?

:9010(SINGLE TOOLSETTING)
G00G30G91Z0
IF[#20EQ#0]GOTO3000
T#20 <<< THROWS ALARM 043 HERE<<<
M6
...
...

Or also in the one:

:9011(MULTI TOOLSETTING)
G00G30G91Z0
WHILE[#19LE#9]DO1
T#19<<< THROWS ALARM 043 HERE<<<
M6
IF[#19EQ#9]GOTO5
T[#19+1.](PRE-CALL NEXT TOOL UP IN T/C)
N5 ...
...

I am trying to use the Renishaw tool probing macros on this old dog, but it's not going well. I've found the alarm description in the manual, but can't find anything else to steer me straight.

Thanks,
John B

[fordav11]

043 is illegal T-code command
check your macro variables page. what are #19 and #20 set to?
it needs to be set to a non-null, non-negative number within the range of your tool rack

[dcoupar]

Can anyone help me understand why my old machine (1990) with the 0m-C control is balking at the T code shown below?

:9010(SINGLE TOOLSETTING)
G00G30G91Z0
IF[#20EQ#0]GOTO3000
T#20 <<< THROWS ALARM 043 HERE<<<
M6
...
...

Or also in the one:

:9011(MULTI TOOLSETTING)
G00G30G91Z0
WHILE[#19LE#9]DO1
T#19<<< THROWS ALARM 043 HERE<<<
M6
IF[#19EQ#9]GOTO5
T[#19+1.](PRE-CALL NEXT TOOL UP IN T/C)
N5 ...
...

I am trying to use the Renishaw tool probing macros on this old dog, but it's not going well. I've found the alarm description in the manual, but can't find anything else to steer me straight.

Thanks,
John B

How are you calling the tool setting macro?

G65 P9010 T11

G65 P9011 S01 T06

or something like that?

[John_B]

How are you calling the tool setting macro?

I call 9011 like this:

G65P9011S4E4

The S pulls over the starting tool #, and E the ending tool #.

And I call 9010 like this:

G65P9010T16D1.5

The T pulls in the only tool to be set, and the D is the diameter.

These exact macros works great on my machine with an 18im-B control. I'm sure it's something that the older 0m-C doesn't like about using the variable reference with the T code. I suppose I could use #4120 and set it at #19, then just call the M6 to load the tool.


:9011(MULTI TOOLSETTING)
G00G30G91Z0
WHILE[#19LE#9]DO1
#4120=#19
M6
IF[#19EQ#9]GOTO5
T[#19+1.](PRE-CALL NEXT TOOL UP IN T/C)
N5
...
...

Do you think that'll work? I can't tell if the #4120 system variable is the tool in the spindle, or the tool called up next by T code for toolchange...?

I can't test it just now as I'm in the middle of running some hot parts that have to ship today. I will be able to monkey with it some more after about 5:00 p.m.

Thanks for the feedback!

Rgds,
John B

[fordav11]

#4001 to #4120 are for reading modal information. the manual states they can be read but
does not specifically say they can be written. so #4120 = #19 won't work since its assumed
to be read only. #4120 is the T number of whatever tool was called last.... i.e. the T in
memory on your model page. try it anyway you never know it may work.
also try using a common variable that stays in memory. for example.....
#500=#19
T#500

also check this thread, post#29
http://www.cnczone.com/forums/fanuc/137761-fanuc_om_lost_tool_change.html

it uses Macro A but has a T#149 and it's an 0-series like yours.
#149 is a common variable but is cleared when the control is powered off.
from #500 upwards they are not cleared at power-off.

another possibility is maybe it needs T#19 M06 on the same line?

[angelw]

I call 9011 like this:

G65P9011S4E4

The S pulls over the starting tool #, and E the ending tool #.

And I call 9010 like this:

G65P9010T16D1.5

The T pulls in the only tool to be set, and the D is the diameter.

These exact macros works great on my machine with an 18im-B control. I'm sure it's something that the older 0m-C doesn't like about using the variable reference with the T code. I suppose I could use #4120 and set it at #19, then just call the M6 to load the tool.


:9011(MULTI TOOLSETTING)
G00G30G91Z0
WHILE[#19LE#9]DO1
#4120=#19
M6
IF[#19EQ#9]GOTO5
T[#19+1.](PRE-CALL NEXT TOOL UP IN T/C)
N5
...
...

Do you think that'll work? I can't tell if the #4120 system variable is the tool in the spindle, or the tool called up next by T code for toolchange...?

I can't test it just now as I'm in the middle of running some hot parts that have to ship today. I will be able to monkey with it some more after about 5:00 p.m.

Thanks for the feedback!

Rgds,
John B

John,
The system variable is not your problem. Typically the modal system variable for the Tool number is used so that the current spindle tool, if its the number being called, is not shifted out of the spindle, or to avoid an error being raised. However, this is somewhat dependent on the PMC program.

Its use would be something like the following, but would normally be in the Tool Change Macro if the machine uses one (also PMC program dependent)

IF[#4120EQ#19]GOTO100 (IF THE CALLED TOOL IS CURRENT, BYPASS TOOL CHANGE)
T#19
M6
N100
.....
.....

I would do as Ford suggested in an earlier post, and check the value of #19 and #20 after the Macro program has been called to see if thy're in the range of the Tool Magazine capacity. However, the use of arguments in your Macro Call to pass values to #19 and #20 should ensure that these variables are set, and therefore, the only way these variables may be out of legal range would be to pass incorrect values. Run the program in Single Block mode, though you will have to set a parameter (#0011.5) so that the program stops after each Macro Statements. If the values are legal, temporarily use a real number, one that is not the current spindle tool, instead of the variable, ie T1 instead of T#19, to see if you get the same error. If you still get the error, it may have something to do with how the Tool Change is executed as suggested by Ford.

Regards,

Bill

[John_B]

Got it, it was the T call and the M6 being on seperate lines for part of it (machine has an umbrella toolchanger).

Worse yet though was that the main setting macro was using the same variable # that the G65 macro was passing the tool number over with, and that was the REAL problem. It was causing all sorts of calculation problems. Once I listed all the variables being used and caught the conflict, all it required was renumbering.

Thanks for the help!

Rgds,
John B