Occasionally fail to change tips

[Jonathan S]

Is it typical for PC-DMIS to fail to execute a tip change in a proven program that has run many times successfully? I have had this happen on occasion in a few programs. I can start the program over and it runs fine on the second try. I have a Mitutoyo retrofit with PC-DMIS 3.5mr2. We have had issues unique to this setup. I'm curious to know if this is one of those issues or if it happens in all different setups including the standard B&S package. I would like to see a response from everyone who reads this.
TIA

[Matthew D. Hoedeman]

It happens on the FIRST tip change in the program, right? It happens all the time.

[rangerboat72]

We have it happen quite frequently (especially after a tool change) on our two Xcel machines with Sharpe 32 controllers. Our newly upgraded to PC-DMIS from Virtual Dmis Merlin machine with a Dea controller has not done it once ? ? ?

[Jeff Hunt]

Matt, I see the same **** thing happen every once in a while. It could turn into a costly problem if an operator isn't paying attention. You would think B&S would want to adress this problem.

[Jonathan S]

Actually Matt, in my case it happens later in the program. One long program I have it happens about 3/4 of the way through a 35 min run. It always happens at the same point in this program, though. The tip change is still there in the program, but it fails to execute. The problem goes away on the next run and it may not return for a while.

[rangerboat72]

I think the problem is in the controller and not the software. Do you have a Sharpe 32 controller on your machine ?

[Matthew D. Hoedeman]

OK Johnathon S, does it happen right after an alignment in the program?

Jeff, why would they fix it? Renishaw wouldn't make as much money, would they?

The problem as I have seen it is the first tip change AFTER an alignment (or the first one in the program if using an external alignment) when using a clearance plane. The 'fix' I have found for it is to insert an INCREMENTAL move before the clearance plane move. The incremental move can be as small as you want (I use a 1mm move in the 'up' direction of my alignment), then let the clearance plane take over.

[rangerboat72]

The 'fix' I have found for it is to insert an INCREMENTAL move before the clearance plane move. The incremental move can be as small as you want (I use a 1mm move in the 'up' direction of my alignment), then let the clearance plane take over.

Matt you are right on !

That's exactly what I started doing and it corrected my problem as well. . .

[RussL]

We have seen the same thing,
sometimes for every tip change in a program,
other times for one or two.
Some days we will see it in almost every program we run,
then we will not see it for a month.
We generally delete probe file, re-boot PC and re-set machine.
Open new program, re-build probe from scratch, save.
Open program we had been working on, make sure features are "marked" correctly and continue.
Don't know if it's related but we have found sometimes tips appear marked but when we re-open, they are not.

[Jonathan S]

Nope, no alignment prior to the tip change. The other issues we had relate to the interface with the controller. I'm not sure what controller is on my Mitutoyo Bright A710, but I'm pretty sure it's not the Sharpe 32.

[John Kugler]

Sometimes I have an issue when I insert something ahead of a feature that is already created. I.E. a clearance plane. Say for example I measure a hole and have the wrong clearance plane. If I go back to insert the correct CP before the hole, it won't recognize the new CP and still use the old one.

Not sure why it does that, but I end up having to redo the hole with the correct CP.

[rebeldude]

I have had that happen more freqeuntly in 3.7 MR2. In fact, it only happens at the start of the program "every once in a while" like Matt said with 3.7 MR3.

Try Mr3 dude

[John Riggins]

3.7 MR3

1 new Global Image
1 old DEA Iota with Sharpe 32
1 old DEA with I-doan-know-what

We have this happen quite a bit on both of the older machines, but only on some programs (same programs on both machines). It was so bad on one program that I put an Operater alert before each Tip index to make sure someone was watching to hopefully catch it before a crash.

It has never happened on the new machine

I am going to try Matt's suggestion about an incremental move.

I will report back when I have results.