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?
We have had PC-dmis completely crash the software, (doesn't show in task manager) but the CMM will still travel in whatever direction is was last moving. This has happened with defined scans and auto features especially cylinders. ...
This may be normal. The controller is simply completing commands that were sent to it. The inspection software sends commands in advance to the controller for performance reasons and the controller can buffer up to ten at any one time. For example, you could send ten move commands in rapid succession and the machine will start moving to complete the first command and continue until until the last one is completed. This could take minutes depending on the distances involved. If PC-DMIS 'disappears' the controller may not realize this and just carries on normally. The controller should detect that the Ethernet connection has dropped and automatically cancel but I don't know how fast that would happen.
... we have also seen where the cmm physically crashes due to the part not conforming and when the E-stop is pushed, cmm moved away, execution cancelled and as soon as the the motors are enabled the CMM will try to go back to the last feature. This has happened on PCD versions 2015 to our current 2022.2 build If_Goto Statements service pack 3 on our Global blues....
That is the problem described in this thread. The controller will try to execute those moves / touches / whatever no matter what happens. E-Stop should stop everything and purge any buffered commands but this doesn't always happen and it resumes when machine start is pressed. If I remember right the problems always hinged around an unexpected touch of the probe.
It is not a PC-DMIS problem (I don't believe it is at least) and, almost certainly, related to the firmware on the controller.
We have had PC-dmis completely crash the software, (doesn't show in task manager) but the CMM will still travel in whatever direction is was last moving. This has happened with defined scans and auto features especially cylinders. ...
This may be normal. The controller is simply completing commands that were sent to it. The inspection software sends commands in advance to the controller for performance reasons and the controller can buffer up to ten at any one time. For example, you could send ten move commands in rapid succession and the machine will start moving to complete the first command and continue until until the last one is completed. This could take minutes depending on the distances involved. If PC-DMIS 'disappears' the controller may not realize this and just carries on normally. The controller should detect that the Ethernet connection has dropped and automatically cancel but I don't know how fast that would happen.
... we have also seen where the cmm physically crashes due to the part not conforming and when the E-stop is pushed, cmm moved away, execution cancelled and as soon as the the motors are enabled the CMM will try to go back to the last feature. This has happened on PCD versions 2015 to our current 2022.2 build If_Goto Statements service pack 3 on our Global blues....
That is the problem described in this thread. The controller will try to execute those moves / touches / whatever no matter what happens. E-Stop should stop everything and purge any buffered commands but this doesn't always happen and it resumes when machine start is pressed. If I remember right the problems always hinged around an unexpected touch of the probe.
It is not a PC-DMIS problem (I don't believe it is at least) and, almost certainly, related to the firmware on the controller.
