False tool break detection

[Cory M. Pio]

Cant you perform a repeatability test on your setter to determine if it is at fault?

You would think but the problem is very intermittent... 

 

Using our normal P9303,,, the "tool measuring is within a tenth or two".... it is a Matsuura.

 

I have been told that when it does this false positive the machine is retracting to the reference points in a feed motion instead of rapid move.

[generaldisarray]

You would think but the problem is very intermittent... 

 

Using our normal P9303,,, the "tool measuring is within a tenth or two".... it is a Matsuura.

 

I have been told that when it does this false positive the machine is retracting to the reference points in a feed motion instead of rapid move.

Retracting back from the touch, like the setter is stuck down?

[Matthew Hajicek - Singularity]

Ooh, that would make sense.  I believe it pushes until the stylus "breaks", but does the actual measurement on the retract.  If it's sticky that would give a false measurement.

[Cory M. Pio]

Retracting back from the touch, like the setter is stuck down?

No, like retracting out of the toolpath and down towards to the tool probe at 18 inches a minute instead of rapiding...

 

So instead of rapiding until the tool gets to .250 above the tool probe and than switching out of rapid to feed... It's just feeding the whole time. It's almost like it's skipping pass that part of the macro.

[crazy^millman]

Is by chance the High Speed command not being turned off in the Macro? I have seen some odd things with look ahead with touch setter, probes and other things over the years. I would trying forcing out everything by hand and not relying on the macro to cancel it. Hard code the cancel commands as part of the cycle and see if that helps your process. Might be shooting dart in the dark, but I have seen this 1st hand it took months before a technician was able to track it down.

[Bob W.]

Not sure if this helps but I had this issue on my Makinos.  Due to the nature of the cutting tools (end mill, bottom is not flat) it would give bad results here and there with the default tolerance of .005".  I went into the Renishaw setting macro and updated the default tolerance setting to .030" and it hasn't happened since.  I don't recall which macro is the setting file but there is a default tolerance that can be changed.  I would assume the Renishaw macros are pretty similar, if not the same for the different machine manufacturers.

[Bob W.]

I should also add that we use a laser.  Sounds like you are using a button style tool setter so maybe it doesn't apply.

[Cory M. Pio]

Is by chance the High Speed command not being turned off in the Macro? I have seen some odd things with look ahead with touch setter, probes and other things over the years. I would trying forcing out everything by hand and not relying on the macro to cancel it. Hard code the cancel commands as part of the cycle and see if that helps your process. Might be shooting dart in the dark, but I have seen this 1st hand it took months before a technician was able to track it down.

ya know ron, I just added "HOF" & "G4 X1." to before my "G65 P9301 B1. M1." 

 

I had this thought today also. What do you think about the dwell?

 

FINGERS CROSSED!!!! Thanks everyone have a good night!!!

[crazy^millman]

ya know ron, I just added "HOF" & "G4 X1." to before my "G65 P9301 B1. M1." 

 

I had this thought today also. What do you think about the dwell?

 

FINGERS CROSSED!!!! Thanks everyone have a good night!!!

 

Dwell for 20 seconds if it keeps your machine running. I want a machine running period.

 

I had a 1 minute clean cycle on one machine years ago and the owner was pissed about that one minute so we removed it against my objections. After he lost a week because of packed up chips the one minute was preventing we put the one minute dwell for the wash out back and never heard another word about it again. I would rather be wrong about an issue I said something about, than knowing let a issue happen without me opening my mouth. We are paid for our expertise and if our experience tells us something is wrong then we must speak up even if it is not popular or well received. Had many people get mad for things I said because I wouldn't agree to then come back later and ask me how did I know? I can't explain it sometimes, but when you have been making chips for 30 years there are just some things you just know and hard to explain.

[dstryr]

So, that 0.250 radius part on the facebook page was done with mcam then?

That was me

 

Cory any luck? That 840 on the matsuura is xxxx backwards to the 840d/828d in my shop >.<

[Cory M. Pio]

That was me

 

Cory any luck? That 840 on the matsuura is xxxx backwards to the 840d/828d in my shop >.<

I don't want no trouble man.

 

The latest is someone came up with a great idea (wasn't me) to add a dwell before the G65p9301 line. She ran last night. 

[Guest]

That was me

 

Cory any luck? That 840 on the matsuura is xxxx backwards to the 840d/828d in my shop >.<

Hence new CUBLEX machines have FANUC controls. :

[Cory M. Pio]

Hence new CUBLEX machines have FANUC controls. :

Matsuura sent us a new Marco.

[dstryr]

Hence new CUBLEX machines have FANUC controls. :

Because Matsuura couldn't integrate the Siemens very well?

[Guest]

Because Matsuura couldn't integrate the Siemens very well?

Or because Siemens support in the US is $#!+...

 

:cough:

[Colin Gilchrist]

I always make sure to check the Look Ahead settings as well. Sounds like you have got this one solved, but it never hurts to dig through the Macros to see if they are manipulating the block look ahead or not.

 

I typically just make sure I've cancelled all High Speed modes before calling Tool Breakage Detection. Your issue is intermittent, so that probably isn't your issue, but it never hurts to check.

 

I've also had issues before with Thru Coolant Drills, where drops of coolant will 'hang' off the end of the drill, and cause issues with the laser devices. So I usually make sure to cancel coolant, and high speed modes, and enable Air Blast (when available), and spin the tool at 50 RPM, while executing a dwell. As a bonus, calling up 50 RPM is a safety measure, just in case the operator needs to do any manual work, like using an indicator. If they accidentally hit Spindle On, or turn it on without thinking (hey it happens), then at least you won't be using the last programmed RPM. I had an operator once that was going to drill a clearance hole in a fixture, and had called up a long drill for the reach. (About 10" stick out) The last programmed RPM was 12K, and the drill bent almost 90 degrees before he could hit the E-Stop.

[Guest]

Something else I just spoke with one of the other guys about... running the tool break cycle (on a laser) at the usual RPM (3,000), tools would often show up as broken. They upped the RPM to 10,000 (obviously not possible for every tool but for those that it is...) and the false breaks went away almost completely.

[Cory M. Pio]

I always make sure to check the Look Ahead settings as well. Sounds like you have got this one solved, but it never hurts to dig through the Macros to see if they are manipulating the block look ahead or not.

 

I typically just make sure I've cancelled all High Speed modes before calling Tool Breakage Detection. Your issue is intermittent, so that probably isn't your issue, but it never hurts to check.

 

I've also had issues before with Thru Coolant Drills, where drops of coolant will 'hang' off the end of the drill, and cause issues with the laser devices. So I usually make sure to cancel coolant, and high speed modes, and enable Air Blast (when available), and spin the tool at 50 RPM, while executing a dwell. As a bonus, calling up 50 RPM is a safety measure, just in case the operator needs to do any manual work, like using an indicator. If they accidentally hit Spindle On, or turn it on without thinking (hey it happens), then at least you won't be using the last programmed RPM. I had an operator once that was going to drill a clearance hole in a fixture, and had called up a long drill for the reach. (About 10" stick out) The last programmed RPM was 12K, and the drill bent almost 90 degrees before he could hit the E-Stop.

Colin,

 

I cannot believe the HOF/HON  commands ,High Speed Look ahead, have anything to do with the failure at this point.

The new P9301 macro that Sean sent from MAtsuura was quite different than our last one. 

The command "stoppre" with in the macro moved and also some dwells were added along with a slower feedrate to the clearance plane of the probe. 

GOing to run by and check to see if the machine is still running tonight. 

 

Crazy story about that drill.

[Colin Gilchrist]

No, I don't think the Look Ahead settings are an issue with your problem, since the failure is intermittent and not consistent. Just something to be aware of in general.

 

But I've also seen weird things with the look ahead buffers holding different information, based on what has previously ran.

 

Say for example, that you've activated a 600 block look ahead. There could be a situation where the buffer is being overran, and that interacts with the machine Macros in strange ways.

 

Again, this probably has nothing to do with your specific issue, but these are things to be aware of to help you troubleshoot Macro issues in general.

 

I've had issues with Block Look ahead cause the "Probe On" Macro to not "see" the results of running that Probe On Macro, because Look Ahead was enabled, but the buffer was basically "empty", and so the Control unit would jump way ahead in the Macro program commands, and the machine would "read" future values too early. But run the same program after executing some High Speed Machining, and now the buffer memory is full of "motion" commands, and now the Probe On Macro executes properly, at least it appears to.

 

Many of the Probe companies like Renishaw have taken these issues into account, and build in capabilities to "save" the current machine modes that are active, disable the active stuff, and then restore those states at the end of the Macro using logic.

 

I think the place where I see these issues most often is when a MTB has built the Macros with the intention that a machinist or setup person will run the measuring cycle in MDI, and now the Programmer is trying to add the Probing cycle output to the NC Program. This is usually not the case with Broken Tool Detection, but you did mention that the new Macro that you received was formatted with some significant differences. Just something to consider. 

[Sticky]

Or because Siemens support in the US is $#!+...

 

:cough:

 

No, the issue is that Matsuura uses Yaskawa drives, motors etc while using the Siemens control, it is a integration issue. When you call Siemens tech support and they hear Matsuura they are not going to want to help. If you call them for tech support for Siemens components on another brand that is pure Siemens (control, motors, drives etc) it is not a problem.

 

The issue is that Siemens wants to blame issues on Yaskawa, and Yaskawa wants to blame the issues on Siemens, and Matsuura doesn't have a good understanding of the machines that were built this way.

 

A pure Siemens build is an extremely reliable control system, likewise with a pure Yaskawa system, and I'd say either are more reliable and more capable than a Fanuc. But mixing the two together was a very poor decision on behalf of an otherwise excellent machine tool builder.

[Guest]

NOTHING is more reliable in the CNC realm than FANUC Controls. That is an undeniable statistical fact. Mean Time Between Failures is measured in the MILLIONS of hours.

 

Why did Siemens buy Yaskawa? That's still a head scratcher.

[Watcher]

NOTHING is more reliable in the CNC realm than FANUC Controls. That is an undeniable statistical fact. Mean Time Between Failures is measured in the MILLIONS of hours.

 

Why did Siemens buy Yaskawa? That's still a head scratcher.

True. But I've seen Siemens running for 10 years on complex 4 channel machines (WFL), two channels for cutting, and two for the tool changer mechanism. Not a single issue. That's a lot if you ask me.

 

The amount of possibilities in a Siemens control, in the user level, just smokes the most modern Fanuc control out there. A 2003 Sinumerik 840d control has more functionality and programming flexibility than the most modern Fanuc these days.

 

So if you ask me how many hours of programming could be reduced or how many cool resources a Fanuc control was unable to deliver to a regular user in 10 years, I would not trade for a MTBF rate I'd not even be alive to witness.

 

Sinumerik 840d sl is by far the most powerful control out there. Fanuc can do a lot too, but certain stuff that are piece of cake in Sinumerik is a ladder or OEM macro in Fanuc.

 

If it was just a small difference, I'd not even bother to mention, but there's a reason the most complex multitasking machines go with Sinumerik.

[Watcher]

Simple example of how Fanuc makes things way more difficult than they should.

 

Cylindrical and polar machining requires your let's say X/Y axis to be called C, and you have to calculate the Cartesian coordinate as angle. Piece of cake for a CAM, PITA if done by hand.

 

Sinumerik: Turn on TRACYL or TRANSMIT before your original cartesian coordinates and the control does the rest for you.

 

Don't get me started on engraving macros...

[Watcher]

When you compare Fanuc to other controls, the MTBF argument is always thrown in the table. I love it, but for me is like saying it's Mastercam V8, without a single bug, very reliable, but can't do what X9 does. Reliability is not everything in this industry. It is crucial and a very big part of it, but not the entire pie.

 

As a matter of fact, we all take lots of risks testing and and playing with buggy cutting edge technology because quite often the benefits overweight the cons. Example: Mastercam dropping the rock solid Volumill to favor their own technology. In the beginning, it was shallow and immature. Look at it now.

 

If you ask me I'd say Fanuc product management is VERY conservative.

[Watcher]

No, the issue is that Matsuura uses Yaskawa drives, motors etc while using the Siemens control, it is a integration issue. When you call Siemens tech support and they hear Matsuura they are not going to want to help. If you call them for tech support for Siemens components on another brand that is pure Siemens (control, motors, drives etc) it is not a problem.

 

The issue is that Siemens wants to blame issues on Yaskawa, and Yaskawa wants to blame the issues on Siemens, and Matsuura doesn't have a good understanding of the machines that were built this way.

 

A pure Siemens build is an extremely reliable control system, likewise with a pure Yaskawa system, and I'd say either are more reliable and more capable than a Fanuc. But mixing the two together was a very poor decision on behalf of an otherwise excellent machine tool builder.

This is an example of how a greed executive can destroy a brand. Someone at Siemens was eager to close the deal with Matsuura and didn't warn them about the poor combination. I'm sure Matsuura would not risk their quality and post sales picking a bad solution in order to save money.

 

Siemens support in Brazil is super B. How can it be great here and bad in the biggest technological and competitive market in the world? It doesn't make sense to me.

 

But a bad choice like that can cause horrible impression on people, and an entire brand and product can be labeled bad because of a wrong decision.