Today I was running a program on our CMM (Global S Green 9.12.8). Stopped the program as it was going to the first clearplane, and then noticed the CMM bridge was still moving. I turned my controller speed down to 0. Tried to modify in the edit window, and it let me, even while it was running. Then I executed my program while it was "running" and immediately hit cancel it again as I did previously to see if it will overwrite the actions it was reading. I then closed PCDMIS. I turned speed up again to see if it was still moving. It was. So I did a full reboot of the CMM, and it's fine now. Has anyone ever ran into this before? A rogue program running even without the PCDMIS software?
I've seen this before. Turned out to be that the machine was "constipated" with data between the PC and the controller. This was an a large machine that could very well have seriously injured people. Fortunately, it only caused 6-7 probe heads and 2 cars to be destroyed. Took Hexagon almost 2 years to find the cause, although they paid for everything except the cars.
I've seen this before. Turned out to be that the machine was "constipated" with data between the PC and the controller. This was an a large machine that could very well have seriously injured people. Fortunately, it only caused 6-7 probe heads and 2 cars to be destroyed. Took Hexagon almost 2 years to find the cause, although they paid for everything except the cars.
Wow. I did not think I'd actually get an answer for this type of scenario. I tried searching and could not find anything on this. Thanks a lot for your reply. I'm glad to hear that no one who was using your machine got hurt by this. The fact that it took 2 years for Hexagon to find the root cause is concerning. How long ago did this happen? If you don't mind me asking.
I seen this too. The company I am thinking of experienced this regularly and got accustomed to it. They could almost recreate the problem. Once the machine got to this stage it was going to complete whatever it was doing regardless of what you did. For example, if you hit E-Stop the machine would stop of course but pick-up where it left off once machine start was pressed. Restarting PC-DMIS didn't help either. The only way to purge the un-executed commands was to reboot the controller or let it complete what it was trying to do.
I am pretty sure it is a firmware bug. If I remember right they were running version 8 on this DC controller. You didn't mention what kind of controller you had but I never heard of anything like this on something other than a DC controller so I assume that is what you have (Global S Green is a fairly new machine and would have this kind of controller). If you happen to be running a newer version of the DC firmware I guess they still haven't fixed it yet (?).
I did bring all this to the attention of Hexagon by the way. A zombie machine is more than a minor problem...
this also happens if we are in the middle of an analog scan and cancel before its completed. the cmm will still keep moving.
This is the problem that I'm familiar with. It seems to happen quite often to me. Hitting E-stop tends to clear it.
I can't say I have ever had it happen while moving to a clearplane the way William describes. Weird.
Cris_C &
Ncogneto, If you are performing DEFINED scans (as opposed to RELEARN or NORMAL), that would explain why cancelling execution from PC-DMIS does not stop the machine. For DEFINED scans, PC-DMIS sends a pre-defined scan path to the controller and enters a waiting mode. The controller then takes over and executes the scan, following the path and gathering the data. It then streams the data back to PC-DMIS and notifies it that the scan is complete at which point PC-DMIS takes over again. That is why the only way to interrupt the scan part way through is to hit the E-Stop.
neil.challinor It may be the case where defined scans cannot be stopped without pressing E-Stop but that is not what I seen and it doesn't appear to be true for the original poster either.
What I seen was on a Global Performance with a DC240 controller, PH10MQ, TP-20 probe. You are just measuring typical stuff (points, circles, ...) and then you can end up in this situation. Nothing short of a controller reboot or allowing it to complete the buffered commands will stop it and that includes pressing E-Stop. This company described it to me and I actually experienced it once when working on the machine. E-Stop shuts the machine off but once machine start is pressed it continues where it left off.
I am almost certain it is a firmware bug. In PC-DMIS, when execution of anything is cancelled, the software sends a binary sequence (similar to CTRL-C or CTRL-Z) that the controller interprets as a stop and purge. For whatever reason the buffered commands are not purged in some cases and you end up with a zombie CMM.
Recreating this is not easy. As I mentioned the company almost could do it but not quite. There is some detail or step missing that was critical to recreating this problem. This company just accepted that this can happen on this particular machine from time to time and deal with it.
neil.challinor It may be the case where defined scans cannot be stopped without pressing E-Stop but that is not what I seen and it doesn't appear to be true for the original poster either.
What I seen was on a Global Performance with a DC240 controller, PH10MQ, TP-20 probe. You are just measuring typical stuff (points, circles, ...) and then you can end up in this situation. Nothing short of a controller reboot or allowing it to complete the buffered commands will stop it and that includes pressing E-Stop. This company described it to me and I actually experienced it once when working on the machine. E-Stop shuts the machine off but once machine start is pressed it continues where it left off.
I am almost certain it is a firmware bug. In PC-DMIS, when execution of anything is cancelled, the software sends a binary sequence (similar to CTRL-C or CTRL-Z) that the controller interprets as a stop and purge. For whatever reason the buffered commands are not purged in some cases and you end up with a zombie CMM.
Recreating this is not easy. As I mentioned the company almost could do it but not quite. There is some detail or step missing that was critical to recreating this problem. This company just accepted that this can happen on this particular machine from time to time and deal with it.
Rondog , when you hit the E-Stop are you sure you are cancelling the program correctly. I always after I am certain I have hit E-Stop then program stop, then cacel that BEFORE I contiue I slow the mcahine all the way down.
