Page 1 of 2

Working fine, then bam!

Posted: Tue Jan 27, 2015 7:35 pm
by chonkat
I was working aluminum for the first time on my stock "full kit" shapeoko 2 and my machine Imagestopped moving along the axes. I was using a 1/8" endmill with easel's settings for aluminum trying a letter with a 1/16" depth.

Basically trying to move any axis the motors just made a sound https://www.youtube.com/watch?v=ajVZ2T6 ... e=youtu.be as if they could not move. the only potentiometer as high as halfway is the z-axis.

I began to wonder if some of the aluminum scraps could have shorted something in the electronics so i powered everything off and cleaned off the electronics just in case. 'I got to prioritize the case for the electronics,' I thought. I rebooted comp and plugged things back in just to have the same thing happen.

I reflashed the arduino with grbl 0.9 and connected through a serial console ('screen' on os x) and could get the settings with '$$'. ImageI could also move the motors through the console using 'y1' 'x1' etc... it moves fast at a default speed.

when i connect with the universal gcode sender though, i get the grbl prompt and can enter commands but there's no text feedback in the console Image.

I'm guessing electronics are ok because they seem fine sending commands directly to the arduino and g-shield.

Suggestions as to what to try next are GREATLY appreciated!

thank you in advance for any advice!

Jon

Re: Working fine, then bam!

Posted: Tue Jan 27, 2015 7:42 pm
by tjshape
In the last screen shot, you are connected at 9600 baud, where you want to be at 115200 baud for the version of grbl you flashed to.


Sent from my iPhone using Tapatalk

Re: Working fine, then bam!

Posted: Tue Jan 27, 2015 8:04 pm
by chonkat
Thanks tjshape! That was it. Did not expect baud to change between grbl version though it's clearly in the filename (grbl_v0_9g_atmega328p_16mhz_115200_for_SO2.hex).

Any disadvantages to using this version of grbl?

Now on to work on the case and on some sort of support for the altocraft spindle's reduced Z clearance (no access to a 3d printer- might order some 1/2" HDPE and try to cut out of that).

Again, thank you.

Re: Working fine, then bam!

Posted: Tue Jan 27, 2015 8:17 pm
by tjshape
No prob, glad that resolved the problem. Be certain to check everything is moving in the correct directions and that the circle diamond square test runs satisfactory for you.

This version has been excellent for me this far. I don't believe it works with Easel though, unless I they've updated Easel since I've stopped using it.


Sent from my iPhone using Tapatalk

Re: Working fine, then bam!

Posted: Tue Jan 27, 2015 8:27 pm
by Caesar S
Downside is Easel works only with grbl 0.8c it doesn't work with grbl 0.9g

Re: Working fine, then bam!

Posted: Tue Jan 27, 2015 9:14 pm
by Gadgetman!
There was a bit of a problem with the G40 command on some 0.9 versions. Not certain if it has been cleared in 0.9g or not.

Earlier versions of GRBL would just ignore G40, then in 0.9, it would throw an error if it came across one. And GRBL will ignore the entire line if it finds an error in it. (A lot of CAM tools will add G40 as part of a line, together with G20/G21, G90 and such, which can cause weird happenings if they're suddenly ignored)

A quick check is to just send a G40 command manually and see if you get an error or not.
If the G40 is on a separate line, there's no problem anyway.
(GRBL is already operating in G40 mode. G41/G42 modes aren't all that high on Chammits todo list)

Re: Working fine, then bam!

Posted: Tue Jan 27, 2015 9:29 pm
by cvoinescu
Gadgetman! wrote:Earlier versions of GRBL would just ignore G40, then in 0.9, it would throw an error if it came across one. And GRBL will ignore the entire line if it finds an error in it. (A lot of CAM tools will add G40 as part of a line, together with G20/G21, G90 and such, which can cause weird happenings if they're suddenly ignored)
Actually, G40 was an error in 0.8 and in 0.9. What changed is that, in 0.9, if there's an error anywhere on a line, the entire line is discarded. In 0.8, GRBL would still execute the "good" bits of the line.

Re: Working fine, then bam!

Posted: Wed Jan 28, 2015 2:16 am
by chonkat
ok, back to v .8c b/c of support as i'm still using easel for most tests to get a hang of the materials and endmills without typing too many values in. yes axes were reversed (tho i could change in setting). later want to try blender with the gcode plugin.
i'm glad to be back in business, still weary of the initial problem though.
CHEERS

Re: Working fine, then bam!

Posted: Wed Jan 28, 2015 3:48 am
by chonkat
Is it normal to connect and have this from the start?


Grbl 0.8c ['$' for help]
��������������������error: Expected command letter
[verbose]<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-6.310>
[verbose]<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-6.310>
[verbose]<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-6.310>
[verbose]<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-6.310>
[verbose]<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-6.310>


found this to clear EEPROM:
http://arduino.cc/en/Tutorial/EEPROMClear#.Uy9oNM74Zkg


/*
* EEPROM Clear
*
* Sets all of the bytes of the EEPROM to 0.
* This example code is in the public domain.

*/

#include <EEPROM.h>

void setup()
{
// write a 0 to all 512 bytes of the EEPROM
for (int i = 0; i < 512; i++)
EEPROM.write(i, 0);

// turn the LED on when we're done
digitalWrite(13, HIGH);
}

void loop()
{
}

Re: Working fine, then bam!

Posted: Wed Jan 28, 2015 10:09 am
by WillAdams
No, that's not normal.

Hopefully clearing the EEPROM will work.