I’m 100% in support of @larryM 's approach.
Thanks guys. I’ll let you know how it turns out.
I followed this link’s instructions:
https://inventables.desk.com/customer/en/portal/articles/2069033-grbl?b_id=9563
I’m on mac, so downloaded the HexUploader app, got it working.
Download the hex file, used the app to upload it, Said at the end:
avrdude : verifying…
avrdude: 28054 bytes of flash verified
avrdude done. Thank you.
But now nothing works: Easel won’t connect, nor will the Arduino itself: The Serial Monitor neither receives or sends comands. I’ve done this process three times now to be sure, powercycling each time.
Gotta run some errands, but would love any thoughts on what’s going on at this point. Again, thanks for your time, super appreciated.
Bummer!
I don’t have a MAC so I haven’t tried that method.
Yet, another alternative is to go straight to the source code. This has always worked for me.
Try this link to compile and load (One change would be to download version 0.9j instead of the one referenced in the instructions).
Source code:
Ok @LarryM, compiling it through Arduino got it working. Whew.
But unfortunately this didn’t solve the problem. When I do the homing bit during the machine setup, it does the exact same thing: Drops the toolhead on Z about half a turn, and then just stops there. grbl is still reporting this:
Idle,MPos:19.064,16.500,-11.160,WPos:19.064,16.500,-11.160,Lim:111
I realize I don’t need the limit switches to make this thing work (I’m used to 3d printers where they’re a necessity), but if there are any other thoughts on the matter I’d sure like to figure out why they have stopped.
Yeah, we need to figure this out, it could be a warning of other things that are bad.
Ok, now disconnect the connector from the gShield that is for the homing switches. Measure the voltage at the gShield for pins D9, D10, and D12. They should be about 5 volts with the connector disconnected.
Also, post the $$ output here.
Unplugged the connector, remeasured: All zero volts. FYI, D13 is 4.77v, but every other pin on that section is zero.
$$ :
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=19 (status report mask:00010011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=35.250 (x, step/mm)
$101=40.000 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)
FYI, I’m pretty sure I have a spare Uno lying around: I can always flash it, replace what’s there, unless it’s an issue on the gshield itself?
The next test would be to remove the gShield and test the pins on the Arduino without the gShield attached.
Also, you can just flash the grbl firmware into your spare Uno and test that without the gShield attached.
It’s either a bad Arduino or the gShield is causing the pins to be shorted to ground.
The pins on the bare Arduino have the same readings, so I’m guessing it’s not a gshield issue.
I found two spare Uno’s, but unfortunately neither of them will take the flash: Whether I compile it with Arduino IDE, or try to use the HexUploader, I get an error:
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x0d
avrdude: stk500_cmd(): programmer is out of sync
And sometimes this:
avrdude: stk500_recv(): programmer is not responding
They’re older Unos, with the bigger Atmel chip in it, but it’s stil a 328P which grbl says it requires. Reading online it sounds like I may need to reburn the bootloader in (?)… but I don’t have AVR programmer laying around, so maybe some other time I’ll tackle that using UnoA to burn in UnoB via the ArduinoISP sketch.
So right now I’m guessin’ you’re going to say there’s something wrong with the Arduino in the xcarve? Man that is weird, I’ve never had one go bad on me.
Yes, it seems to be a problem with the Arduino.
So after much work (than it should be, my mac is driving me bonkers) I got a new bootloader on one of my spare Uno’s, and Grbl reflashed. Here is the $$ output. It looks… weird, for a default reflash. Really huge numbers for X acceleration and max travel, and zero value for Y & Z. Should I just set them all back to some previous value from the above thread?
$0=255 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=255 (step port invert mask:11111111)
$3=255 (dir port invert mask:11111111)
$4=1 (step enable invert, bool)
$5=1 (limit pins invert, bool)
$6=1 (probe pin invert, bool)
$10=255 (status report mask:11111111)
$11=2147483.648 (junction deviation, mm)
$12=2147483.648 (arc tolerance, mm)
$13=1 (report inches, bool)
$20=1 (soft limits, bool)
$21=1 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=255 (homing dir invert mask:11111111)
$24=2147483.648 (homing feed, mm/min)
$25=2147483.648 (homing seek, mm/min)
$26=255 (homing debounce, msec)
$27=2147483.648 (homing pull-off, mm)
$100=2147483.648 (x, step/mm)
$101=0.000 (y, step/mm)
$102=0.000 (z, step/mm)
$110=2147483.648 (x max rate, mm/min)
$111=0.000 (y max rate, mm/min)
$112=0.000 (z max rate, mm/min)
$120=2147483.648 (x accel, mm/sec^2)
$121=0.000 (y accel, mm/sec^2)
$122=0.000 (z accel, mm/sec^2)
$130=2147483.648 (x max travel, mm)
$131=0.000 (y max travel, mm)
$132=0.000 (z max travel, mm)
If you are running version 0.9j from the Inventables fork then send this command $RST=$
That should set your defaults for the X-carve. If you have a 1000mm machine then you might have to change $130 and $131 to 790
AH, that looks much better now, thanks!
Update on this: I checked the digital pins on the new grbl loaded uno: They all read close to 5v, which tells me they should actually support the limit switches. So that’s good…
However, the whole thing doesn’t work: Even though (on the ‘old but updated Uno’) I can query the grbl firmware vals from both the Arduino IDE & from the ‘Advanced settings’ in Easel, when I go to do the machine setup, I can’t jog the steppers at all. No sounds, nothing. I unplugged the limit-switches, but that didn’t make a difference. Swap for the ‘shipped with x-carve’ uno\gshield combo and it scoots all over. Swap back to the ‘old but updated’ uno\gshield, and dead in the water.
Comparing my ‘old but updated’ uno to the ‘shipped with x-carve’ uno, I notice the x-carve one has more header pins the gshield plugs into. At this point I’m guessing that Arduino Uno’s aren’t created equal, and the other ones I have are ‘just too old’.
Maybe I’ll get around to buying a ‘newfangled uno’ eventually, but since right now I’m cutting just fine without the limit-switches, that’ll be a future project. Thanks for all the help though!
I had a problem where the header pins / mini-molex connector for the limit switches had a lot of play inside it. The wires wouldn’t pull out and weren’t loose really, but when I plugged the connector onto the G shield it pushed one header pin out instead of connecting, causing the homing switches to not work and sending me on a hardware/software goose chase. Since everything is so small it was hard to see that a crimp connector wasn’t seated inside the plastic housing right. It felt right, didn’t pull out, but didn’t actually connect to the board. I know you said you checked for loose wires but sometimes it pays to go a little deeper.
Thanks for the info @Mike : I think at this point it boils down to the Arduinos: The limits did work a-ok for a single day, so I’m confident the wiring on them is ok. It was a very binary change: Everything worked, execute a home via chilipeppr, then everything breaks (note I have chilipeppr working now). Issue now is the x-carve Arduino has zero volts on the digital pins for the limits (so it’s not reading their on\off states even if the wiring is correct), and my refurbished Arduino that has positive voltage for the limits won’t drive the steppers.
If you want to check it out try reading this:
How dis you fix the problem? Thanks!
I never did, looks like it was maybe a bad Arduino. I have another thread here on which Arduino / firmware to use:
Haven’t gotten around to it yet though, since in general homing switches aren’t needed.