Missing physical motor move - but thinks it has moved
Hi,
I am using this on Spiderbot. I am just finishing the construction and currently just testing.
Using the Reptier-Host I seem to have full and flawless control. I have played with the fans, moving the head with jog commands, used a little "wave in the air" Gcode on one of the script buttons, heated and cooled ... in short everything seems to work.
A couple of times, it seemed as if one motor (not the same each time) was "stuck" or unresponsive. A restart always cured it and given I am just starting to use the machine I was eager to try the next thing. Also sometimes a move command seemed to get "lost" (ie. none of the motors moved)
Then I tried the G29 (z-probe auto level). This seemed to work fine, and I used it several times. I then used the Park button, and the machine did not move. "I might have missed the button" I thought and entered another G29 command. This caused the head to dive hard into the bed, leaving marks and all. It seemed the software thought it had moved to the high Park position by the P button but not actually moved. So the G29 command had a lot of distance to cover, but the head was in the wrong place.
I am a little at a loss where to start looking for the problem. Baudrate? Some other protocol setting (it is in PingPong mode)? What external sensor stuff could block a physical movement but still make the software think it was done? Is a floating input a possible trouble source (causing too many interruptsor something?) The Linenumber/checksum protocol, should it not ensure that no commands are lost?
Tanks for all and any suggestion, Msquare
I am using this on Spiderbot. I am just finishing the construction and currently just testing.
Using the Reptier-Host I seem to have full and flawless control. I have played with the fans, moving the head with jog commands, used a little "wave in the air" Gcode on one of the script buttons, heated and cooled ... in short everything seems to work.
A couple of times, it seemed as if one motor (not the same each time) was "stuck" or unresponsive. A restart always cured it and given I am just starting to use the machine I was eager to try the next thing. Also sometimes a move command seemed to get "lost" (ie. none of the motors moved)
Then I tried the G29 (z-probe auto level). This seemed to work fine, and I used it several times. I then used the Park button, and the machine did not move. "I might have missed the button" I thought and entered another G29 command. This caused the head to dive hard into the bed, leaving marks and all. It seemed the software thought it had moved to the high Park position by the P button but not actually moved. So the G29 command had a lot of distance to cover, but the head was in the wrong place.
I am a little at a loss where to start looking for the problem. Baudrate? Some other protocol setting (it is in PingPong mode)? What external sensor stuff could block a physical movement but still make the software think it was done? Is a floating input a possible trouble source (causing too many interruptsor something?) The Linenumber/checksum protocol, should it not ensure that no commands are lost?
Tanks for all and any suggestion, Msquare
Comments
Anyhow, I have seen the problem now in many forms. Here is a video - http://youtu.be/2etaQ3mGxb4?t=1m22s - which shows a simple example. At that point (1:22 in the video) I am just nudging down on the Y axis. At one point one of the motors (left pole) stops moving. I then do a Home command and there it moves without problem.
Current theory is two causes: The Megatronics board simply does not move the motor (overheat tripped, end stop switch loose or something), or the Firmware (version 0.91-k) does some optimization wrongly.
I should add this is on the Megatronics 3.0. The driving software is the Repetier host 1.0.5
Still, learned a lot during this "exercise".