All motors fail test (2)

I got to the calibration step of this guide ( but nothing was happening when I would press extend. When I was testing the motors/encoders all of the motors failed the test. One time the left motor moved, but I haven’t been able to replicate that. Also, the Z axis is way off. I’d appreciate any help; I’ve been stuck on this for 2 days. Here are some pictures:

I’m sorry for the trouble! That sounds like a tough one to figure out. Thanks for all the pictures, the answer all the questions I would normally start with.

The fact that the green power LED is on means that the shield is getting power so it isn’t a power supply issue. The fact that all the motors fail the test is very strange because the left and right motors are on completely separate circuits and having them both be bad seems very unlikely.


Do you hear any noise during the test? Does the green power LED in the picture stay lit through the entire process?

I don’t hear or see any change in the motors when I run the test and the green light stays on. When I am testing the right motors though the Vel goes way up into the millions/billions range while vel stays at 0 on the left motors and Z axis

Hmmm that is very very very strange. The only thing that I can think is that it could be the Arduino or the Arduino Shield since those are the only components shared by both motors. It sounds like you have tested everything that I would have recommended testing. If you send an email with your address to we’ll send you a new Arduino and Shield right away.

I don’t quite understand this sentence:

Do you mean that it moves when pressing the button, but not the correct distance?

I was talking about how on the third image down the z axis says 393953.93 while X Y and Vel all say 0.00. Thanks for the quick help, i’m used to waiting for hours for responses.

1 Like

Got it! Thanks for clarifying.

I think this sounds like a hardware issue (although I’ve never seen one like it before), but one more thing that might be worth trying while we wait for the post office to open tomorrow is to wipe the Arduino’s memory and the memory of Ground Control. You can do that by pressing Actions -> Advanced


After resetting the settings in Ground Control the program will close, and after wiping the EEPROM you will want to unplug the Arduino and then reconnect.

I’m not optimistic it will be the answer, but it’s one more thing we can try

The z axis and vel are now at zero during testing, but all of the motors still fail.

this sounds sort of like the situations where a stop had been issued and
something needed to be done to un-jam things


Good suggestion @dlang, while we are waiting for the hardware to arrive I will look into that. My hunch is that the test motors function will override the stop command even because it’s a very low level test, but I’ll confirm that by testing today.


@dlang is 100% correct. The safety lockout for the stop can prevent the motors from moving during the “test motors/encoders” function. I wasn’t able to replicate the behavior you saw where the test would run with all the motors failing, instead I simply didn’t see the test start at all. The solution was to press the “Stop” button several times. This will bring the machine to a normal state and let the test proceed

1 Like

Can we make the “Stop” change it’s appearance in some major way when it is blocking? Hot pink maybe?


That is an excellent idea. We have to be careful to coordinate it with the firmware which is actually blocking. What if as a quick solution we just printed some text to the terminal every few seconds so that there would be a visual cue as to what was going on on the machine side?

1 Like

That would be good, and maybe GC could trigger on that text to do something on the screen. Can we add something (short) onto the end of the <Idle,Mpos…,Wpos…> message like a stopped flag?

Do we need to transmit all the time? That would make showing a status indicator like the stop button color in GC easy but it could interrupt GRBL comparability. What would the GRBL way to do this be?

Update: It looks like it was right in front of my eyes and I missed it, from the GRBL standard:

Grbl's status report is fairly simply in organization. It always starts with a word describing the machine state like IDLE (descriptions of these are available elsewhere in the Wiki). The following data values are usually in the order listed below and separated by | pipe characters, but may not be in the exact order or printed at all. For a complete description of status report formatting, read the Real-time Status Reports section below.


So we should just change the word Idle to Hold or something similar and look for that in GC, right?



1 Like

By pressing the down arrow I was able to get the alarm notification you mentioned and that did stop the test from going through without any message. Pressing the stop button once was enough to clear that and get it to start printing again. I manually calibrated the machine using made up numbers to try to rule out that it was a calibration issue, before doing so i was getting an alert that said that these were invalid chain lengths every time I’d press the stop button. However, after pressing the red stop button 200 times all of the motors are still failing.


I’ve opened issues in GC and firmware - I’ll let you make the changes, yes?


Sounds good, I’m on it!


I got the new arduino and shield and it’s working perfectly. Thanks!


This post was super helpful because after having cut my new sled and having calibrated it, mysteriously my cnc just stopped working, right in the middle of positioning it for my first project. Long story short is that I mounted my power supply on the back of the main 4x8 sheet of plywood and the vibration from cutting and moving wiggled the power cord just enough so that it was no longer in contact and although everything looked like it was plugged in properly, it wasn’t. Maybe not a good idea to mount the power supply brick on the back of the board.