What's new
What's new

Renishaw RMP40 P9810 MC3086 PATH OBSTRUCTED

fjs0001

Plastic
Joined
Jun 26, 2020
Hello,

I have two Doosan HC400 Horizontal Mills each with a Renishaw RMP40 probe. They are running the same programs. They both were running, but now I'm having issues with one of the machines. I use the probe to find the center of a hole. I use the P9810 program to protect the probe as it approaches the measuring position incase the robot misloaded the part. When the probe reaches the measuring position, it faults out for a "MC3086 PATH OBSTRUCTED" alarm even though it never touched anything. I tried a new probe and it did the same thing. The machine would do this every once in awhile and I'd power down the machine to clear the fault. Then it would run fine for days, weeks, or months. Now it won't run at all.

Here is the beginning of my program leading up to were it faults out.

O1528
#501=2.2129
#502=.546
#503=.555
#504=.22
M20
B0
T36M6(PROBE TOOL CHANGE)
T205(PRE-CALL NEXT TOOL)
G90G54.1P44(POSITION CALL)
G0X0Y0(RAPID MOVE TO X,Y LOCATION)
G43H36Z4.0(TOOL L COMP, H OFFSET, Z POSITION)
M74(TURNS ON PROBE)
M165P9810Z-.220F350.(PROBE POSITION MOVE) This is where is faults out.
M165P9814D1.6430S145(MEASURES BORE - S STORES G54.1 P45)
G0Z8.0(MOVES OUT PROBE)

Thank you for your help.
 
Good day, I work for Doosan. This might sound strange but you may be triggering that probe prematurely with that 350IPM feed rate. Have you slowed it down to test? There is also a tiny screw on the side of the probe to adjust the trigger sensitivity. If you find that this may be the issue, you must recalibrate the probe.

Paul
 
this could be an issue. Where are the machines located in relation to each other? If the machines are facing each other, it's possible for the transducer to read the probe on the wrong machine.
 
this could be an issue. Where are the machines located in relation to each other? If the machines are facing each other, it's possible for the transducer to read the probe on the wrong machine.

:crazy:

Never thought of that.........:eek:

Note to self: Change floor plan layout for future shop.
 
Last edited:
Good day, I work for Doosan. This might sound strange but you may be triggering that probe prematurely with that 350IPM feed rate. Have you slowed it down to test? There is also a tiny screw on the side of the probe to adjust the trigger sensitivity. If you find that this may be the issue, you must recalibrate the probe.

Paul
Hello Paul, I have tried slowing it down in the program and turned the feed rate override all the way down. I have even held the probe in my hand while the machine was running. It still faults out as soon as it hits the programmed position of Z-0.22. My probe tool length is 5.42". I can only recalibrate it using GUI if I set my tool length to zero. After calibration it sets my probe length to 0.8". If I try to recalibrate the probe with the 5.42" tool length, the table backs away from the probe very slowly in Z+. I have put new batteries in the probe and tried an entirely new probe.


this could be an issue. Where are the machines located in relation to each other? If the machines are facing each other, it's possible for the transducer to read the probe on the wrong machine.
The other machine blew a coolant line, so it wasn't running either, and I was still having this issue.
 
could it be that you're rapiding up in Z without doing a saftey move out?
I've been spoiled by WPS, so I haven't done longhand probing for a while. But I always did 5 lines, turn on, saftey move in, measure, safety move out, turn off.

As always, the line you get an error on may not be the line with the problem.
 
Hello Paul, I have tried slowing it down in the program and turned the feed rate override all the way down. I have even held the probe in my hand while the machine was running. It still faults out as soon as it hits the programmed position of Z-0.22. My probe tool length is 5.42". I can only recalibrate it using GUI if I set my tool length to zero. After calibration it sets my probe length to 0.8". If I try to recalibrate the probe with the 5.42" tool length, the table backs away from the probe very slowly in Z+. I have put new batteries in the probe and tried an entirely new probe.


The other machine blew a coolant line, so it wasn't running either, and I was still having this issue.


This could be a number of things. First, it sounds like there may be some bad calibration data. Maybe it's not the O9810 line causing this. O 9810 only throws an alarm IF the probe is triggered BEFORE it reaches the programmed position and only if it's triggered. Your machine is making it to Z-.220 so I don't think that is the problem. The next line of code is going to measure a bore. Something is wrong where the machine thinks it can't make it to the destination with either the diameter value for checking or the calibration data is saying "wait, I can't get to that position".

Something might have happened to your RENGui config data also. The machine is no longer setup the way it should be. Have you compared config data from the good machine against the bad machine? Like, is the probe radius .1181 or is it 118" or 3"? Metric numbers versus Inch numbers?

RENGui uses the #500 variables by default for various things yet you have #500 variables in your program. Look in RENGui config.

Calibrating a probe, you MUST set a work offset prior and activate that work offset to calibrate the probe on the same surface you set the work offset to.

You may need to call Renishaw or get your Ellison dealer to come take a look . I will be back in the office on Monday. You can call me at 973-618-2457 and I can try to help you.

Regards,
Paul
 
It seems that probe is not yet switched on while O9810 is executed .
RMP is a bit slow on SWITCH ON.
Edit the SWITCH ON procedure and add PROBE SWITCH ON CHECK as follows:

T36M6(PROBE TOOL CHANGE)
T205(PRE-CALL NEXT TOOL)
G90G54.1P44(POSITION CALL)
G0X0Y0(RAPID MOVE TO X,Y LOCATION)
G43H36Z4.0(TOOL L COMP, H OFFSET, Z POSITION)
(*********************************)
M73 (SWITCH OFF ANY PROBE)
G4X0.1
M74(TURNS ON PROBE)
G4X1.
(PROBE SWITCH ON CHECK)
#101=#5043
G31Z[#5043-0.0004]F2.4
G53
#102=#5043
G0Z#101
IF[ABS[#101-#102]GT0.0002]GOTO10
#3000=99 (PROBE SWITCH ON FAILURE)
N10
(****************)
 
This could be a number of things. First, it sounds like there may be some bad calibration data. Maybe it's not the O9810 line causing this. O 9810 only throws an alarm IF the probe is triggered BEFORE it reaches the programmed position and only if it's triggered. Your machine is making it to Z-.220 so I don't think that is the problem. The next line of code is going to measure a bore. Something is wrong where the machine thinks it can't make it to the destination with either the diameter value for checking or the calibration data is saying "wait, I can't get to that position".

It's definitely P9810 because I wrote a tiny program where it only runs P9810 and it still faults out for PATH OBSTRUCTED.

I can't see the 9810 program, but I put the machine in single block and this is what it does. I'm running the machine without a part in it, so the probe can't touch anything.
1. It moves to Z-.22, I then turn the feed rate knob to 0%
2. I press cycle start 17 times and it gives me a 0% feed rate override alarm. I increase the feed rate, but the machine doesn't move.
3. I press cycle start 4 more times.
4. It then runs this program twice.
M185
M73
G4X.1
G5.1Q1
M99
5. I press cycle start two more times and then I get the PATH OBSTRUCTED alarm.

RENGui uses the #500 variables by default for various things yet you have #500 variables in your program. Look in RENGui config.
All the configure data is the same as the machine that is running.
 
I'll second the suggestion that it may be the probe on command. I've seen this with RMP600's, they take about 2 seconds to fully turn on even tho the green lights will flash. You'll get that kind of path obstruction alarm. Try putting a 2 second dwell after the probe on, before any movement and see if you still get the alarm.
 
It seems that probe is not yet switched on while O9810 is executed .
RMP is a bit slow on SWITCH ON.
Edit the SWITCH ON procedure and add PROBE SWITCH ON CHECK as follows:

T36M6(PROBE TOOL CHANGE)
T205(PRE-CALL NEXT TOOL)
G90G54.1P44(POSITION CALL)
G0X0Y0(RAPID MOVE TO X,Y LOCATION)
G43H36Z4.0(TOOL L COMP, H OFFSET, Z POSITION)
(*********************************)
M73 (SWITCH OFF ANY PROBE)
G4X0.1
M74(TURNS ON PROBE)
G4X1.
(PROBE SWITCH ON CHECK)
#101=#5043
G31Z[#5043-0.0004]F2.4
G53
#102=#5043
G0Z#101
IF[ABS[#101-#102]GT0.0002]GOTO10
#3000=99 (PROBE SWITCH ON FAILURE)
N10
(****************)

I tried this program, but it didn't alarm out for (PROBE SWITCH ON FAILURE).

My probe tool length is 5.4271
This program set #101 to 9.4271
The G31 moved the machine pallet away Z+ from the probe 5.4267
The machine set #102 to 14.8538
It then ran P9810 and gave the PATH OBSTRUCTED alarm.
 
I'll second the suggestion that it may be the probe on command. I've seen this with RMP600's, they take about 2 seconds to fully turn on even tho the green lights will flash. You'll get that kind of path obstruction alarm. Try putting a 2 second dwell after the probe on, before any movement and see if you still get the alarm.
I tried a 5 second dwell and still received the PATH OBSTRUCTED alarm. :wall:
 
It's definitely P9810 because I wrote a tiny program where it only runs P9810 and it still faults out for PATH OBSTRUCTED.

I can't see the 9810 program,.....

You should change parameters to allow you to see the program.

Have you compared 9810 to another machine's 9810? Almost sounds like there's something edited out of it.
 
You should change parameters to allow you to see the program.

Have you compared 9810 to another machine's 9810? Almost sounds like there's something edited out of it.

I changed the 3202 NE9 bit to 0, but I still can't see inside the program.

It did give me a slightly different view of it running though. It looks like it tries to run the P9810, but jumps out, then tries to run it again, but jumps out again, turns off the probe, then tires to run it again and alarms out.
 
It's definitely P9810 because I wrote a tiny program where it only runs P9810 and it still faults out for PATH OBSTRUCTED.

I can't see the 9810 program, but I put the machine in single block and this is what it does. I'm running the machine without a part in it, so the probe can't touch anything.
1. It moves to Z-.22, I then turn the feed rate knob to 0%
2. I press cycle start 17 times and it gives me a 0% feed rate override alarm. I increase the feed rate, but the machine doesn't move.
3. I press cycle start 4 more times.
4. It then runs this program twice.
M185
M73
G4X.1
G5.1Q1
M99
5. I press cycle start two more times and then I get the PATH OBSTRUCTED alarm.


All the configure data is the same as the machine that is running.


Well, the program you show here is the Probe End program. It is turning off the probe and turning AICC back on.

This program should run first.
O8501(PROBE START)
M184(G01 INTERLOCK OFF)
M74(OMP ON)
G4X1.
G5.1Q0(AICC OFF)
M99

Then, the O9810 and O9814 should run as in your program.

Then this program should run after all probing is done.
O8503 (PROBE END)
M185(G01 INTERLOCK ON)
M73(PROBE OFF)
G4X1.
G5.1Q1(AICC ON)
M99

The other programs you won't see run because they run from the macro executor. They are NOT in machine memory.
 
OK, both were running properly at one time. What happened? You cannot change any of the Renishaw programs themselves because they are embedded in the macro executor. Did you make any changes whatsoever? Parameters? This is the first time I have seen this issue with the M165 calls. Something got messed up. And you did not answer my earlier question. Did you call your Ellison dealer and have them come out to help. You could have gotten this solved already.

Paul
 
OK, both were running properly at one time. What happened? You cannot change any of the Renishaw programs themselves because they are embedded in the macro executor. Did you make any changes whatsoever? Parameters? This is the first time I have seen this issue with the M165 calls. Something got messed up. And you did not answer my earlier question. Did you call your Ellison dealer and have them come out to help. You could have gotten this solved already.

Paul

The machine would fault out for PATH OBSTRUCTION every once in awhile over the past year and I'd power down the machine. It would run fine for days, weeks, or months after powering it down. Now it won't run at all. I started using #503 & #504 recently, but nothing was store in those variables beforehand. I tried setting them both back to zero, but that didn't help. The program ran fine using #503 & #504 for a month besides the occasional fault and I'd restart the machine.

I'm sorry, what was the question I missed?

I tried calling Ellison all day Friday, but no one ever answered. I've talked to two people from Renishaw, but they were stumped as well. The corona virus has everyone working from home, so I think it's harder for them to trouble shoot stuff.
 
I just paid attention, that you are running the protected move on F350. feedrate (M165P9810Z-.220F350.(PROBE POSITION MOVE) This is where is faults out.), while the Renishaw's FAST FEED default, set in O9724, is 200 IPM. Too fast feedrate in O9810 can cause false trigger. Lower the feedrate significantly (F50.) and try again.
 
The machine would fault out for PATH OBSTRUCTION every once in awhile over the past year and I'd power down the machine. It would run fine for days, weeks, or months after powering it down. Now it won't run at all. I started using #503 & #504 recently, but nothing was store in those variables beforehand. I tried setting them both back to zero, but that didn't help. The program ran fine using #503 & #504 for a month besides the occasional fault and I'd restart the machine.

I'm sorry, what was the question I missed?

I tried calling Ellison all day Friday, but no one ever answered. I've talked to two people from Renishaw, but they were stumped as well. The corona virus has everyone working from home, so I think it's harder for them to trouble shoot stuff.


fjs0001,
My mistake, I just spoke with Renishaw and the PATH OBSTRUCTED alarm can only be caused during the protected positiioning move, O9810.

I also noticed this in your previous response.
M185
M73
G4X.1 (This should always be changed to X1.0) This short dwell has caused problems for us in the past)
G5.1Q1
M99

This program O8501 is in memory, you can find it in the LIBRARY folder. It can be edited.This is the probe start program.

O8501(PROBE START)
M184(G01 INTERLOCK OFF)
M74(OMP ON)
G4X1.
G5.1Q0
M99

This program O8503 is in memory, and can also be found in the LIBRARY folder. It also can be edited.

O8503 (PROBE END)
M185(G01 INTERLOCK ON)
M73(PROBE OFF)
G4X1.
G5.1Q1
M99

There are two more for the tool setter. They give a small amount of control to users when the macro executor programs cannot be changed.
 








 
Back
Top