Zach: when I first set it up, everything was going in the correct direction, both when jogging the steppers, and when homing. It all ‘just worked’ I was quite happy I saw the option to ‘reverse their direction’, but I didn’t need to use it.
Should I just reflash the arduino at this point back to factory default? (and if so, is there a handy link…?)
Not yet. Let’s start with a power cycle and disconnecting the USB. Closing Easel, IDE, and Chilipepr. Then open Easel power on and plug in the USB.
Do you have/know how to use a voltmeter? If so, measure the voltage with respect to ground on the Arduino pins D9,D10, and D12. These pins are brought up by the gShield and that is where you plug in the homing switch connector.
From the left D9 is the 2nd position, D10 is the third position, and D12 is the fifth position.
@Zach_Kaplan : done, everything turned off, on, and only thing open now is Easel. FYI, I havn’t had chilipepr on since yesterday. Currently it’s off limits
@LarryM : I do, just checked. All zero volts, open or closed, read on the board, and on the switch itself. It’s like there is no juice going out to them. I did confirm my meter is working right, reads 24.4v across the incoming line.
@Zach_Kaplan Unless Zach has something else to try then here is what I would do.
[Edit]Hum, you did measure the voltages with the connector removed, right?
Ok, there’s something wrong with the electronics. Assuming the connector is still removed. It may be a simple set up issue because the Arduino is supposed to be pulling those pins high with internal resistors.
At this point I would try to reload the grbl software to see if it is just a software issue.
You can do it this way:
Or this way:
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:
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.
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).
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:
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!