Fookin last friday, I did an alignment on a fixture and ran a master part multiple of times, but I didnt like one of the move points, so I inserted a new move point. Somehow the CMM went retarded and drove the probe right into the dam table. Bent the **** out of my 3mm probe and busted the module because it was in A0B0. Has anyone else have had this happen to them? Not even a year old global s green and running 2018R2. 2nd time in a month.
The CMM crashed atthepoint that is highlighted. Even after the crash and I put in a new module and probe/re-calibrated. Moved the probe over to were this move point is using the probe read-outs window. It showed that the Probe should have went to this xyz location given in the code. Since the CMM maintained alignment.
Execute it block for block with the speed way down. Put a stop before your T1A0B0 rotation until you're confident that you won't crash.
Make sure you don't have an avoidance move...clearance cube...depth..messing you up. Quadruple check that your move points are the correct coordinate.
Theres gotta be a a reason and we'll help you find it.
I am NOT saying these things are your issues..but I follow a few rules that keep me out of trouble and I recommend you consider following these two in particular:
1) If any of my alignments are recalling an external alignment, make sure the external alignment has all 6 degrees of freedom constrained (Level, rotate, XYZ Origin).
2) Adhere to a strict naming convention. No spaces or special characters in naming fields EXCEPT underscores. (ex. I'd have called your alignment "OFFSET_3074")
It's not obvious from the picture which tip is active when you do the MOVE - you change tip immediately after, maybe you meant to insert the MOVE after the tip change?
I had something similar happen to me before when I was running a program and was viewing another program offline. It flipped a move point and tip change code (supposed to clear part then rotate) in the running program and caused a crash. I'm 99.99% sure the program was fine beforehand, we run production with read only files. After that I've never opened an offline program while somethings running on the machine.
The tip stays at A0B0. I have tip change callouts in the program for different parts. That way I can just do some fine tuning instead of writing a whole prg.
The crazy thing is. I came in Monday and did that. Ran it slow and from block to block. Everything ran fine with no change, infact I'm running cores right now on this program. Maybe the reader glitched on the z axis scale. Not sure.
If your on the road long enough you will eventually crash......
Many years ago, I wanted to add a 1/4 inch movment on a move point. Fat fingered it and made an attempt at a 21/2" move at ramming speed. There was stuff in the space I was attempting to move thru. Completely broke off my $15,000 PH9 indexing probe head from the quill
There's also the resource leak effect - when (no IF involved!) PC-DMIS or any other Windows program has been running 'long enough', small resource leaks (tiny programming errors) have accumulated enough to make Windows say NO instead of returning the new memory area, file handle, window handle, whatever, that the program is asking for. What happens next depends on the code's ability to handle unexpected errors like that. Most software contains parts of code where the programmer thought "that can never happen, so no test is needed".
The result is unexpected, non-repeatable behavior, crashes, etc.
The only remedy is to regularly restart the program in question - my recommendation, both for PC-DMIS and Microsoft Word (for example) is to start each working shift with a newly started software (no need to reboot the whole computer if you're running Windows Vista or later).
