SV-2412 tool change macro question

I'm trying to troubleshoot a random tool change problem on my SV-2412.

I am comparing my tool change macro to others from the same machine.

Here is the code:

:9001
#3003=1
#3004=1
IF[#100EQ#4120]GOTO99
IF[#4120EQ0]GOTO99
IF[#1011EQ1]GOTO99
G91G28Z0.
G91G30Z0M19
M9
M6

<snip a bunch of semi-colons>

G04X0.1
IF[#1008EQ1]GOTO10
GOTO99
N10G91G28Z0
IF[#1009EQ1]GOTO12
GOTO10
N12G91G30Z0
G04X0.5
IF[#1010EQ1]GOTO99
GOTO12
N99#100=#4120
#3003=0
#3004=0
M99
%

Question is, what does the N99 line do? What do those registers #100 and #4120 represent?

On my machine, that line isn't there, it has this instead:

N99 #3003=0

I looked at old backups, they are the same. AFAIK, it has always been like this, but I think it might have been edited a long time ago.

The problem is the intermittent hang on the M6 after the M9. This is not unknown on these machines, but I have never seen a definitive solution to the issue.

Control is Oi-Mate MB

Apparently I have a different version of that macro that does not use those variables. Here is mine:

%
O9001
#3003=1
#3004=1
IF[#1011EQ1]GOTO99
G91G28Z0.
G91G30Z0M19
M9
M6

(39 semi-colons)

G04X0.1
IF[#1008EQ1]GOTO10
GOTO99
N10G91G28Z0
IF[#1009EQ1]GOTO12
GOTO10
N12G91G30Z0
IF[#1010EQ1]GOTO99
GOTO12
N99#3003=0
#3004=0
M99
%

I've read threads on that other board about adding a dwell before the #3003=0 line, but that doesn't have any effect on my machine.

I'm weak on macros and am trying to grasp what those variable arguments are actually doing.

this is storing system variable #4120 the active T Code into variable location #100 - most likely for someone to verify what the active T code is at that point in the macro

Tom said:

this is storing system variable #4120 the active T Code into variable location #100 - most likely for someone to verify what the active T code is at that point in the macro

Click to expand...

Thanks Tom. Since my macro is not doing that I assume it isn't that important.

What I am trying to figure out is how to troubleshoot the tool changer hangup. It's intermittent at the M6 line in the macro- not on every tool change, but random. When it stops it just sits there forever, and I have to reset out and call the tool change again.

It acts like it's dropping the signal from either the G30 limit switch or the spindle orient sensor or brake. I think those are the variables 1008-1011, but I don't know which is which, or how to view their state in the diagnostics.

guest said:

Thanks Tom. Since my macro is not doing that I assume it isn't that important.

What I am trying to figure out is how to troubleshoot the tool changer hangup. It's intermittent at the M6 line in the macro- not on every tool change, but random. When it stops it just sits there forever, and I have to reset out and call the tool change again.

It acts like it's dropping the signal from either the G30 limit switch or the spindle orient sensor or brake. I think those are the variables 1008-1011, but I don't know which is which, or how to view their state in the diagnostics.

Click to expand...

Hello jancollc,
If you truly feel that its to do with the G30 then #1010 is the bit signal being sent from the PMC in relation to it.

IF[#1010EQ1]GOTO99

Its not a well thought out Macro, as if the G28, or G30 signal is never made, the Macro will hang indefinitely in those areas respectively. A better option would be to include a Timer Function within the Loop for these two signals and if the bit status returned was not "1" within the set time, control would branch to an error trap to report the error.

If the program example in your Post #2, is all one program, I don't quite get the logic.

1. It starts by executing G28 and G30 without any signal from the PMC

2. Then executes M6, which would be treated as an ordinary M Code, as program O9001 has been called as a Subprogram via an M Code (M06)

3. Then launches into repeating the G28 and G30 with bit checking.

To check your theory that the G30 (or G28) may be an issue, you could embed a Variable in the G28 and G30 check loops and observe their value when the fault arises. Some thing like the following:

N10G91G28Z0
IF[#1009EQ1]GOTO12
#101=#1009
GOTO10
N12G91G30Z0
IF[#1010EQ1]GOTO99
#102=#1010
GOTO12

Regards,

Bill

angelw said:

Hello jancollc,
If you truly feel that its to do with the G30 then #1010 is the bit signal being sent from the PMC in relation to it.

IF[#1010EQ1]GOTO99

Click to expand...

Thank you Bill. Can you tell me where I have to look to see the state of #1010?

Also, is there one for the spindle orient signal too?

angelw said:

Its not a well thought out Macro, as if the G28, or G30 signal is never made, the Macro will hang indefinitely in those areas respectively. A better option would be to include a Timer Function within the Loop for these two signals and if the bit status returned was not "1" within the set time, control would branch to an error trap to report the error.

Click to expand...

What happens is the indefinite hang. It executes the G28, G30, M19, and M9 just fine.

Then it sits on the M6 forever...

angelw said:

If the program example in your Post #2, is all one program, I don't quite get the logic.

1. It starts by executing G28 and G30 without any signal from the PMC

Click to expand...

Right. The first part of the macro is positioning the head at the intermediate reference position and orientating the spindle.

You can call a tool change in a program no matter where the Z position happens to be- it will G28 Z and drop the spindle down to the the tool change position (G30).

angelw said:

2. Then executes M6, which would be treated as an ordinary M Code, as program O9001 has been called as a Subprogram via an M Code (M06)

3. Then launches into repeating the G28 and G30 with bit checking.

Click to expand...

When the M6 executes, it activates the shuttle, then the unclamp, raise the head, rotate the carousel, and lower to the G30 position, clamp the tool and retract the shuttle.

angelw said:

To check your theory that the G30 (or G28) may be an issue, you could embed a Variable in the G28 and G30 check loops and observe their value when the fault arises. Some thing like the following:

N10G91G28Z0
IF[#1009EQ1]GOTO12
#101=#1009
GOTO10
N12G91G30Z0
IF[#1010EQ1]GOTO99
#102=#1010
GOTO12

Click to expand...

The fault always occurs at the M6 line. If it gets past that line, the rest of the tool change happens fine. That makes me think it's losing the signal on the first instance of the G30. Or the spindle orient. e.g. the machine does not get permission to move the shuttle in for the tool change, so it is just waiting...

I am wondering if I should add that bit checking at the first set of G28 and G30 moves? Would the syntax be the same?

guest said:

Thank you Bill. Can you tell me where I have to look to see the state of #1010??

Click to expand...

Hello jancollc,
You can't view it directly. You will have to allocate its value to a Macro Variable and then view it. For example:
#100 = #1010
Then view #100

guest said:

Also, is there one for the spindle orient signal too?

Click to expand...

There may be an interface signal for it, but its not being used in the program you have listed.

guest said:

What happens is the indefinite hang. It executes the G28, G30, M19, and M9 just fine.

Click to expand...

In the program you have listed, it has the potential to hang in the:

N10G91G28Z0
IF[#1009EQ1]GOTO12
GOTO10

and

N12G91G30Z0
IF[#1010EQ1]GOTO99
GOTO12

areas of the program.

1. If #1009 never returned a "1" value, the program would indefinitely loop between the GOTO10 and N10G91G28Z0 Blocks.

2. If #1010 never returned a "1" value, the program would indefinitely loop between the GOTO12 and N12G91G30Z0 Blocks.

guest said:

Then it sits on the M6 forever...

Click to expand...

Without the benefit of viewing the PMC Ladder, if the Tool Change Hangs at the M6 (it seems like the actual Tool Change is carried out by the PMC), its likely that the PMC Ladder is internally checking for a proximity switch for G30 being made.

guest said:

I am wondering if I should add that bit checking at the first set of G28 and G30 moves? Would the syntax be the same?

Click to expand...

You could and syntax will be the same. However, you would need to use unique GOTO and Sequence Numbers for the bit checking in the new areas.

You could also do something like the following:

%
O9001
#3003=1
#3004=1
#100=#0
#101=#0
IF[#1011EQ1]GOTO99
#1=0
G91G28Z0.
N1 #100 = #1009
G04 X0.01
#1 = #1+1
IF[#1LT3]GOTO1
#1 = 0
G91G30Z0M19
N2 #101 = #1010
G04 X0.01
#1 = #1+1
IF[#1LT3]GOTO2
M9
M6
The #1 Counter and Dwell simply provides the opportunity for the #1009 and #1010 Interface Variables to be read. The PMC Ladder is continually scanned from Top to Bottom. There is a Scan Rate overhead to deal with and its possible for a signal to be missed in the scan rate period, hence the reason for a few repeats of the action.

If/when the program hangs at M6, view the value of #100 and #101 before resetting the program. This will tell you the status of G28 and G30 being made (likely to be a proximity switch inputs for both)

Regards,

Bill

Thanks Bill. I will digest this.

Here's another data point. When the program hangs on the M6 line, the spindle brake is released. The spindle orients like it should- but I am thinking if the brake releases before the tool change, it's going to halt the cycle.

If I MDI a M19, it orients and the brake sets. It stays set until I hit the reset button, so I don't think it's a mechanical problem.

On Fanuc controls, the signal for orientation complete is labeled ORAR or ORARA. I don't have docs for an Oi series control so can't point you to a specific address. You might look at Diagnostic F45 bit 7 to see if that is ORAR or ORARA on your control. If it is or you figure out which F address it is, you can monitor it for stability during the toolchange. It should be 1 when the spindle is oriented and 0 when not oriented.

I have seen machines where the toolchanger is not well aligned to the spindle cause the ORAR to turn off due to dragging on the tool flange and cause the process to hang.

Well I seem to have stumbled onto an odd workaround on this tool change behavior.

Just finished up a job- 1000 pcs., cross drilling a .098" hole in a stainless M8 FHCS. Utterly simple, center drill, drill. 2 tools.

Code for each tool is identical, other than tool 1 is a G81 and tool 2 is a G83. Doesn't get any simpler:

%
O0004
N1G17G40G80G90
T1M6
S1250M3
G0G90G54X0Y0
G0G43H1Z1.M8
G81Z-.063R.1F2.
G0G80Z1.M9
G91G28Z0.
M01
N2G17G40G80G90
T2M6
S1300M3
G0G90G54X0Y0
G0G43H2Z1.M8
G83Z-.38R.1Q.045F2.0
G0G80Z1.M9
G91G28Z0.
G28Y0.
T1M6
T1M6
M30
%

Notice I am calling T1M6 twice at the end. I did that so I could hit the reset button when the tool change hangs- when it drops back into the main program I can hit cycle start and run the T1M6 again.

It always performs the second instance of T1M6 without problem. Also, the tool change from tool 1 to tool 2 always goes fine.

I ran about 450 cycles, with the tool change hanging about 50% of the time on the T1M6. Hit reset, hit cycle start, program completes, load the next part. Gets old...

So I was asking myself- what's the difference between the first tool and the second tool? Other than the G81/G83, the two tools run the same code. But the program always starts with tool 1 in the spindle, so it just reads and ignores the T1M6 at the start of the program.

What the hell- I added another T2M6 right before the T1M6's at the end. Since tool 2 is already in the spindle, it just ignores the call. But here's the crazy part- it ran the remaining 550 parts successfully executing the T1M6 on the first instance.

Now tool 2 looks like this:

...
N2G17G40G80G90
T2M6
S1300M3
G0G90G54X0Y0
G0G43H2Z1.M8
G83Z-.38R.1Q.045F2.0
G0G80Z1.M9
G91G28Z0.
G28Y0.
T2M6
T1M6
T1M6
M30


Is that nutty or what? I will remove one of the T1M6's at the end- I left it in there because I expected to need it. But after 550 cycles without hanging, I am pretty sure it's going to run all the way through next time I make the parts.

Is it because T1 M6 needs a small delay on this machine ?