no joy flashing a Due so I tried grbl on a mega2560 (there is

no joy flashing a Due so I tried grbl on a mega2560 (there is an official port).

using a terminal - all is absolutely fine. I get the anticipated response from each command I try.

using SJPS and CP I get absolutely no response at all from the arduino. Most bizarre.

here is a debug log from sjps:

2017/04/23 11:53:57 serialport.go:233: Got p.sendBuffered. data:$G\n, id:status, pause:0
2017/04/23 11:53:57 bufferflow_grbl.go:68: BlockUntilReady() start
2017/04/23 11:53:57 bufferflow_grbl.go:72: New line length: 3, buffer size increased to:95
2017/04/23 11:53:57 bufferflow_grbl.go:73: &{0xc422cac870 0xc420111320 32 0xc42012a818 95}
2017/04/23 11:53:57 serialport.go:268: Got p.sendNoBuf. id:status, pause:0, data:$G\n
2017/04/23 11:53:57 serialport.go:275: Items In SPJS Queue List:0
2017/04/23 11:53:57 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:57 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:57 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:57 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:58 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:58 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:58 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:58 bufferflow_grbl.go:385: Just wrote 1 bytes to serial: ?
2017/04/23 11:53:59 hub.go:122: sendjson {“P”:"/dev/cu.usbmodem621",“Data”:[{“D”:"$G\n",“Id”:“status”}]}
2017/04/23 11:53:59 bufferflow_grbl.go:238: Command Before Break-Apart: “$G\n”
2017/04/23 11:53:59 bufferflow_grbl.go:268: Re-adding newline to item:$G
2017/04/23 11:53:59 bufferflow_grbl.go:271: New cmd item:$G

i can’t see what could cause the device to respond flawlessly to a serial terminal and not to SJPS. unless somehow SJPS isn’t happy to talk to the non FTDI chips (this is an Atmel 16u2 I think (difficult to see the tiny letters with my old eyes).

I’m trying on a mac at the moment (using 1.94 sjps). I will give it a go on windoze but I don’t see why there would be a difference (except maybe 16u2 drivers?).

Any thoughts?

exactly the same behaviour on windoze.


one thought is that CP does not give the mega enough time to wake up. it needs at least one second after a serial port reset.

the grbl widget definitely waits three seconds before hitting the controller with queries but it is possible that some other modules start spamming earlier.

yes. it is a timing issue. something in the CP world starts spamming the controller far too quickly.

workaround is a 1uF between reset and gnd. but that is a terrible solution.

As far as i know, the mega2560 version of grbl is not compatible with chilipeppr. I tried time and time again, but i just does not work.

If you get it to connect (only possible with the tinyg driver) it skips most steps of the job and ruins your material.

I asked @jlauer ​ for help but he just told me to connect with the grbl driver over and over, wich does not work.

In the end i switched to bCNC. It works flawless and is absolutely compatible with your firmware.

You can still render gcode with chilipeppr and use it in bCNC.

Hi @Mano_Biletsky_Open_M

the primary issue is that CP spams the board before it has been released by the boot loader. You can work around this with a cap, or burn the firmware with no boot loader (you’re then limited to burning each time with SPI).

however I am not getting any motor movement at all.

on switching back to an Uno, i find the same is true. So it looks like in the experimenting I have completely fried all three axes on my controller board.

nope not fried.

found the issue.

the board pinout on a mega2560 is not compatible with a gshield. you have to wire in the two pins that are not connected on a mega that, on an Uno, would be connected to reset and IORef. when I did that I got motor movement at least.

can you explain (@Mano_Biletsky_Open_M ) how you are connecting the mega2560 and the gShield ? or are you using another controller?

if you are using another controller, then try using the /jpadie workspace with the mega2560 but put a cap across reset and ground. you may well need to force version 1 mode too (this option is in the dropdown on the right hand side of the grbl widget).

for me - I am giving up on this route now as board incompatibility is too much of a headache to resolve.

I’m running grbl 0.9j on a Nano (mega328p). I advise you to run it on a Nano or Uno. Just compile and program over Arduino IDE. My clones have CH340/CH341 usb-serial. (FTOBTCC remember?)

LE what driver does your gshield use?

it is a possibility but at the moment I have no jumper cables to hand. certainly not enough to wire all the necessary pins.

I don’t have any spare unos. the only one I have is that which @jlauer suggested has a faulty (intermittently) usb chip.

For the usb chip burn a simple serial ascii sender from Arduino exampler and let it run a few minutes. I doubt it has issues. Or wire an external ftdi. The lack of jumper wires can be solved by some spare header pins and soldering iron or some cat5/6 cables, just don’t expect them to make contact all the time, desperate times ask for desperate measures (:

yes - i am deliberately avoiding having to solder the boards. that would be a step further than I am willing to take for this project.

I could use a serial sender, yes. that may be an idea.

If I don’t use the soldering iron, a few rolls of duct tape or a few dozen zipties it’s not a good enough project (:

I’ve used single core cat5 instead of dupont on a few breadboards.

I use Chilipeppr ability to flash the firmware and Due programming port. I put the file to a apache web server on a linux host in my local network and enter link to the bin file.

@Justin_Adie can you post a screenshot because i’m confused again what scenario you’re in and a screenshot could help solve? It doesn’t make sense that you can send to your Uno from a terminal and not from ChiliPeppr. Is it something as simple as you have the serial port still open in the terminal app so the serial port is locked?

there are a number of scenarios here @jlauer . With the grbl and gshield configuration you advised yesterday that the issue may be with the usb chip on the Uno. It is a possibility. Screenshots won’t add anything over the debug output above - nothing else happens visually.

the Uno is working in every other respect on every other sketch that I have tried.

I don’t have any other Unos to try so I used a Mega2560. The bootloader is different on this and it waits for 1000 msec to see whether there is an incoming sketch. Unfortunately there is something that is writing to the serial port in that time. It is not the grbl widget as that waits politely for three seconds before sending requests. I was not able to track down which widget was writing to the board unfortunately.

In any event, the mega 2560 is not a precise match to the genuino and certain pins (ioref and reset) are not exposed. But in any event, the grbl mega code uses completely different pinouts to the Uno and I don’t have any jumper cables to match them up. I need to order some.

For the same reason I cannot try any of the nanos that I have.

So I then tried to move to a Due with g2core. I have not been able to calibrate my z axis. Seemingly the config can only take an integer and that is not nearly granular enough for me to get accurate travel on the T8 leadscrew that I am using (2x microstepping).

I got movement, finally, on the Due but cannot get any meaningful probing done. In fact when I click on the trial-run button within auto-level widget, the z-axis rises about a cm and then falls again. FAOD - the axis is definitely configured in the correct orientation - no doubt about it.

Overall I genuinely feel that the profit/loss on milling (since December) has been enormously on the red side. I’ve enjoyed playing with the software but I have not got a single (literally none) usable milled piece out at the end.

I had about fifteen projects I wanted to prototype. If I’d sent the boards to China in December when I bought the mill, I would have been able to iterate at least three times in the time I have spent getting the mill and its electronics to work.

But as I said, I have enjoyed bug-fixing the software. So that’s something.

What I would recommend to be productive is get a TinyG and a 3040 and never look back. I’m super productive on mine, but I never was productive on my Shapeoko with Grbl. So I can understand where you’re coming from.

I’m still confused after your most recent post as to whether you’re actually getting a serial port locked problem though and from your first post i’m still confused what the scenario is. I know you think a screenshot may not help, but a screenshot shows so much detail that I scan it to see if any warning signs trigger in my brain. My gut right now is you might have just set the baud rate wrong and a screenshot would show that even though it wasn’t an area you were guessing.

Genuinely not @jlauer ​. I’m not sure what scenario you are now referring to but the only data points that were visual were those i posted yesterday. When milling a job the tick vanishes, the mill pauses, and i have posted the output from sjps. There is zero visual feedback from the Uno that suggests anything is awry.

If you are referring to something else then i need a bit more of a pointer.

I’m sure an alternative start point would have been better but the money has been spent and the budget did not stretch to anything more than i have. Beggars can’t be choosers as the expression goes.

Just trying to help you get the issue solved on “using SJPS and CP I get absolutely no response at all from the arduino.” and here’s the stuff we’d need to know:

  1. are you able to successfully open the serial port (the debug data isn’t super helpful there cuz you could be trying to send when serial port isn’t actually connected)
  2. what baud rate are you connected at (nothing in your posts show that)
  3. what buffer flow algorithm are you picking
  4. what workspace are you in.

@jlauer ​. The serial log shows the middle of a milling job. So from that we can discern that the port can be opened and communication is successful. The baud rate for grbl is 115200.
The workspace is /jpadie. But as you said yesterday you believe this is an issue with the usb chip.

There is no screenshot to share. The mill is disassembled and i will recycle the electronics and sell off the gshield.

End of the road!

@Justin_Adie ​ Did you try Due with workspace?
I can imagine you are not happy with current results, but maybe we can try it one more time? I’ll get my Due setup up and running tomorrow and maybe we could try get you on the track once more?