Live Part Alignment Machine Crash

[chohmanQ74YB]

Machine Crashed Following the Probing Operation for Live Part Alignment Data

My goal is to utilize the machine work probe on a HAAS GR510 for live part alignment to locate a production part held in a vice. At this time there is not a fully designed and validated fixture setup, therefore I saw it as an opportunity to test out and utilize live part alignment to locate the XYZ of the part in space. Here is a photo of the setup.

During the test run the vice was purposely not indicated for alignment along the X axis to test the capabilities of live part alignment. The program was setup to probe two points on each side of the part (XYZ) to restrict all degrees of freedom for aligning the part correctly. The program probed all of the 6 points on the part and prompted review of the data and asked for approval. I did not analyze the data close enough to notice that some points failed to project. See the inspection results before and after part alignment.

I pressed approve and immediately the machine lowered the probe and crashed into the part at the location of the last probing point. I have attached the inspection report along with the nc code for investigation. 

What would cause the machine to lower into the part after it just probed the surface locating the top z surface? Was the machine crash a result of the probed data not able to successfully project onto the part? Was the crash a result of the machine trying to make a tool change, but first lowering the height of the head to the tool carousel height?

Let me know if anyone has any ideas. For now I have limited the programs to probing the WCS instead of full live part alignment.

[Richard.stubley · Accepted solution]

Hi @chohmanQ74YB,

Firstly, as a fellow probe wielding machinist sorry to hear this has happened. Regardless of Setup, operator, software or hardware issue it's never a nice feeling to see the probe hurtling towards the part! Lets dig into this and see where the problem could be. Your description gives me ideas already but lets start from the basics and look at the code. 

The code for live connection isn't too easy to read as it's lots of macro calls. 

Lines 470 to 477

WHILE [#10110 NE 3] DO1

(WAITING FOR WCS UPDATE)

G53

IF [#10110 EQ 2] THEN #10110= -2

IF [[#10110 EQ -2] AND [#10111 EQ 3]] THEN #3006 = 1 (PART_ALIGNMENT_ALARM)

IF [[#10110 EQ -2] AND [#10111 EQ 3]] THEN #10104 = 2

IF [#10110 EQ -2] THEN #10110 = 0

IF [[#10104 EQ 2] AND [#10111 EQ 3]] THEN M30

END1

In English this is our loop while you are deciding whether to approve the alignment or not. 
There are a few options here, we can alarm the machine, or even stop the program instantly with an M30 if you reject the alignment. 


This hasn't caused the issue as there are no moves here, however shows us where to start looking. 
There is then another load of macro calls. Lines 479-485. This is updating the WCS then telling Fusion it has done so. 

488-500 This is loading the next toolpath in the live alignment, again no moves yet just communication. 

Now line 500 is a G53 G0 Z0 This is where I suspect the issue to be. Why, it's the first motion move since the alignment where we know all was good, and 3 lines later after nothing more than a comment and a M1 there is a tool change. 

So I'm 99% certain that is was line 503: G53 G0 Z0 that the crash happened on. 

Now to why this could have caused a crash.... 
Could live alignment have adjusted something in the wrong direction? Very possible, however this is in machine co-ordinates. For live alignment we adjust the WCS I dont think we could adjust the machine co-ordinates even if we intended to. So I don't believe it was anything to do with Live connection and part alignment.

This would have got me stumped however when you said. "Was the crash a result of the machine trying to make a tool change, but first lowering the height of the head to the tool carousel height"

On your machine where is Machine G0? is it the bed or bottom of the Z stroke, or is it the top of the Z stroke?

On Most Vertical milling machines Machine Z0 is almost as high as it can go and considered to be safe. I'm wondering on your router if this is actually the bed height, or tool change height. Is the tool change height below the part height? Is this normal for you?

I'm guessing this isn't the first time you have run Fusion and this machine. However maybe the first time with this post and the machine? Do you normally use a different setting in the post property "safe retracts" do you normally use G28 rather than G53 for example. 

If you could confirm if Machine Z0 would have been low enough to cause this then that looks like our answer. However I would like to understand why this hasn't happened before. There is the same line at 118 G53 G0 Z0. But maybe this was in a different X and Y location that meant it was fine to GO to that position. 

Do you have some NC code that contains a tool change and works an you have run before please? I'd like to look at that too.


In short I dont think it was any of the inspection stuff that did this it was the safe retract of machine Z0 actually being lower than the part. 

[chohmanQ74YB]

Thank you @Richard.stubley for the detailed analysis!

I believe your analysis is correct that the line 503: G53 G0 Z0 is the root cause of the machine crash. I reached out to the Haas applications engineering department to further understand the nature of the movement of the GR510 when commanded to make moves through the g code. The engineer confirmed that with the G53 line of code utilized for safe retracts in the post processor the machine will lower (in my case) to this height in preparation for a tool change at the tool change height based on the machine setup. Here is the GR510 layout drawing for reference.

I believe the solution to this moving forward is to utilize G28 as the safe retract height in the prost processor to command the machine to move to the Z zero machine limit then jog over to the tool changer, lower the height and proceed with the tool change.

This has has not happened in the past with the G53 safe retracts selected due to the height of the parts being machined, but in some cases it is very close. Based on my height stack up analysis, utilizing G53 safe retract there is a clash in the height of the part at the tool change height. 

I will analyze the movement of the machine for programs currently running with G53 safe retract. I will also test out G28 safe retract to observe whether this will be a confirmed solution moving forward.

[Richard.stubley]

Hi @chohmanQ74YB,

Thanks for the info. So it sounds like this part has been the highest one you have machined on this machine so far. So although this may have happened in the past, your part has been low enough to miss. 

I spoke to a HAAS engineer over here in the UK about this ad he just warned that G28 may go to the same spot as G53 depending on  how its been setup. So possibly using the clearance height so its a value in your WCS might be the better option than G53 or G28. 

Another option would be to modify the post so rather than G53 G0 Z0. its G53 G0 Z50. (I've put 50 in as a guess, basically whatever is the Highest X you have)

Clearance height would be my guess now knowing a bit more about what's going on. 


Hopefully this at least lets us know where the issue was. 
Back on your description of what you were trying to do the only advice I would have is maybe a 321 alignment. Otherwise known as plane line point. This can sometimes be more reliable than 3 lines. 

[Tomek.G]

Hi @chohmanQ74YB

I'm really sorry what happened.
You can set the home position either in the post processor or
if you are using the machine definition connected in the setup you can change the home position in the kinematics tab of the machine definition