I purchased a J TECH laser and trying to re-flash my SO3 control board w/ J TECH’s GRBL, however, I can not flash anything to the control board.
While using a MAC < Hexloader < I RCV this message;
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
When using X-Loader on my Windows machine, it just hangs there with no response.
Serial/COM port and baud rate setting are good on either OS I use because I can send g-codes to my SO3 via universal G-code sender or Carbine Motion and it works.
I have inserted a hyperlink to the ShapeOko forum below.
I’m attempting to reflash my v2.3 board w/Estlcam CNC code and same issue with the bootloader inhibit.
I’d like to ensure I can reflash with GRBL successfully before attempting the Estlcam reflash.
I’m presuming that the v2.3 CM controller board requires the same exercises?
Can someone on the Carbide 3D support team or anyone else verify this?
I’ve been told this switch is interposed with the DTR line and that’s the reason I’m experiencing consternation while trying to save/reflash the controller contents with Estlcam?
I’m curious @atrueresistance, did you have to reconfigure any GRBL settings after upgrading to the GRBL v0.9j reflash?
FINALLY was able to try this, but first attempt failed using Xloader and GRBL 0.9j… my target controller is a v2.2 Carbide Motion PCB.
COM port = 3 (Shapeoko3 in Device Manager)
Baud rate = 115K
Device = Uno(ATmega328)
Hex File? (Pasted the ASCII from this link into a file using Notepad / http://bit.ly/1I8Ey4S)
Xloader sat there and locked up requiring Task Manager abort.
Does one need to manually reset the controller?
I’m ultimately wanting to reflash this v2.2 controller with the Estlcam CNC controller code but that won’t flash the board, either? Hence my experimentation with trying to establish a manual reflash (note my v2.2 controller has no PROG pushbutton like v2.3/v2.4)
The v2.2 controller works just peachy with Carbide Motion. Same cable, power supply, etc.
Sorry bro…I don’t have anything worth while to give on this post. Once the Carbide Crew advised on a replacement control board (2.3) I have not had an issue with my SO3 & JTECH laser. Keep in mind I’m novice as they come. Please continue to share because I’m always listing and learning.
I too am running a v2.3 board… since laser is in my future I’d love to learn more about your experience.
My interest in the v2.2 board is to run the Estlcam CNC controls and use all the excellent features of this software (integral touch plate tool changes, contour mapping, STL file cutting, etc.)
I just registered on the Shapeoko forums as there’s not a lot of traffic in this unsupported section…
What should be a stupid, simple reflash is NOT working. Based on what I’ve read in this thread, I’ve come to the conclusion that I have GRBL flashed, but no bootloader: http://www.shapeoko.com/forum/viewtopic.php?f=3&t=8127
I’ve tried virtually every combination of baud rate, power on/power off, reset-reflash to no avail… it should not be this difficult.
Soooooo, the only way to root this is via an IDE and “ISP” (and not an Internet Service Provider,). I have lots of experience with other embedded mCU’s (PIC and ICD2/ICD3 using “ICSP”) and (MSP430 and FET430 using “JTAG/SBW”). I’ve had zero experience in the Arduino realm, nor do I have much in the way of Arduino boards or tools.
Anyone else in the community dabbling or has dabbled with reflashing that could enlighten me?
Based on what I’ve tried and the non-results I’ve experienced along with more research I’m convinced that my CM v2.2 PCB does not have a bootloader. I do have some AVR JTAG tools acquired from a startup liquidation, however I’ve been told the AtMega328 does not support JTAG.
My best recourse at this stage I believe is to get hold of another UNO board that does have a serial bootloader and use it for reprogramming the v2.2 controller board.
Has anyone here done this that could point me in a resourceful direction?
If those things don’t help, I’d suggest adding a new post at the end of that thread on the Shapeoko forums and someone who actually understands this stuff should be able to help.
I also have a couple tactics to try and I’ll scour your links as well.
The GRBL wiki page you cite implies there is a bootloader for serial flash support, however I can’t get my CM v2.2 PCB to accept/acknowledge anything. Can anyone @Carbide or someone in the know confirm the bootloader question?
Hi Jim
I could do with some help if you don’t mind?
I’ve flashed the estlcam successfully onto my Nomad Pro and have managed to do some basic movements of the machine so it would appear that I am going to be able to use Estlcam which is great.
In the meantime though I’d like to revert back to Carbide Motion to run a few tool programs I need that are already to go with the old software. Here in lies the problem, I’ve told Estlcam to restore which it has done but the homing is not working on any of the axis so the travel in any direction causes an error.
I’m used to using CM3 so haven’t bothered with version 4 yet.
I note you’re managing to switch between programs so I thought you’re the man to ask.
Best regards
Stephen
My switching is a bit misleading, specifically I have two carbide motion controller boards, one flashed with grbl, and the other with estl.
I have not had to rely upon the estlcam restore operation, but it sounds like something is off. You should be able to reflash your cm controller to grbl 0.9 and take it from there. You could also consider flashing to grbl 1.1
I have updated to GRBL 1.1 but there seems to still be a problem in that I can’t home the machine. Pressing the home button merely drops the Z axis 5mm and then I get an error - it does flash up with a door open message momentarily during the 5mm of movement which is odd and then CM reverts back to the ‘Initialize Machine’ screen so I could repeat this until the Z axis bottoms out. The position shows x=0, y=0, z=-5 and this doesn’t change no matter how many times I try to home.
I’ve un plugged the door magnet switch entirely from the board and it still does the same even though when it is connected the door open switch works fine.
I had a Skype for 30 mins with Jorge and he suggested a faulty Z limit switch and so he’s very kindly sent one to me along with a brand new board. Can’t fault the service!
Anyway on the topic of Estlcam, it clearly works with GRBL 1.1 and I think I’d like to continue to use it but I think I may have to do something about the switches for homing. If I understand correctly the tool depth switch on the Nomad operates in closed position and if I want to continue using the tool depth switch in Estlcam I need to swap the switch for ‘open’ type so that I can then wire a pair of crocodile clips in series to act as my probe switch?
Can you tell me am I completely off the mark here or have I got that right?
P.S. just in case you spot something glaringly obvious I’ve included my log file of GRBL below.
(192): <- ok
(191): -> $132=100
(190): <- ok
(189): -> $131=250
(188): <- ok
(187): -> $130=250
(186): <- ok
(185): -> $122=270
(184): <- ok
(183): -> $121=270
(182): <- ok
(181): -> $120=270
(180): <- ok
(179): -> $112=1270
(178): <- ok
(177): -> $111=2600
(176): <- ok
(175): -> $110=2600
(174): <- ok
(173): -> $102=200.0
(172): <- ok
(171): -> $101=200.0
(170): <- ok
(169): -> $100=200.0
(168): <- ok
(167): -> $32=0
(166): <- ok
(165): -> $31=2000
(164): <- ok
(163): -> $30=10000
(162): <- ok
(161): -> $27=5
(160): <- ok
(159): -> $26=25
(158): <- ok
(157): -> $25=1000
(156): <- ok
(155): -> $24=100
(154): <- ok
(153): -> $23=0
(152): <- ok
(151): -> $22=1
(150): <- ok
(149): -> $21=1
(148): <- ok
(147): -> $20=0
(146): <- ok
(145): -> $13=0
(144): <- ok
(143): -> $12=.01
(142): <- ok
(141): -> $11=.02
(140): <- ok
(139): -> $10=3
(138): <- ok
(137): -> $6=0
(136): <- ok
(135): -> $5=0
(134): <- ok
(133): -> $4=0
(132): <- ok
(131): -> $3=1
(130): <- ok
(129): -> $2=0
(128): <- ok
(127): -> $1=255
(126): <- ok
(125): -> $0=10
I concur with the homing issue and at least with Shapeoko’s, the Z-axis always travels upward first to the limit switch , then X & Y take off.
I’m unclear as to what tandem of CAM and sender program you ultimately want to use… when using the tool length probe in the CAM operations of Estlcam I’m presuming it relies on the probe pin which you can easily invert in the input tab of CNC controller setup.
What I don’t know is how the tool-depth probe of the Nomad is wired to the CM controller… it’s likely on the probe pin, but I am guessing.