Missing physical motor move - but thinks it has moved

Msquare

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

Repetier

Park only works after homing (G28). Also autoleveling should only be done after homing. I Normally home go down to have a small distance and then run G32 S2 to autolevel and save result. But only after I adjusted the endstop offsets in eeprom with 

G131

M99 X0 ; Then move slider to a defined hieght which you repeat with y and z

M99 Y0 ; I use a rod I put between defined level and slider. After 10 seconds motor goes on again to hold position

M99 Z0

G132 S2  

Yes checksums prove all commands get send and nothing gets lost. Firmware will ignore moves outside allowed area, e.g. below Z0 (only zprobe or with S1 in G1 this is possible)

Msquare

If the Park command is ignored, then why did the system think it had moved it to the Park position when the next G29 command moved to a start position with a slight above Z0 but actually did a dive to a spot well below the physical 0?

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

Msquare

The matter has been solved. The steppermotor drivers overheated and had thermal shutdown.

Still, learned a lot during this "exercise".

Twistedair

Not just my machine headbutting the heated plate then...