missing/deleted image from Google+
missing/deleted image from Google+
Uno R3 is on the back. Hmmm…and these pictures are not as good as I thought they would be.
ok. that uses a 16u2 usb chip. you will need to upgrade the firmware on that chip.
see here for more info: https://github.com/gnea/grbl/wiki/Known-Issues
hmmm…so grbl 1.1f and a newer arduino firmware too?
the usb firmware rather than the arduino bootloader, yes.
Alright. Thanks for the information. I hope I can manage to update the usb firmware okay.
i just found that i have the same old firmware - i wonder whether that has been a source of my issue all along!
hahaha…maybe we helped eachother out then. Okay. Would you like to upgrade your stuff, specify what you updated to what version and give feedback on the results?
Well, I managed to get mine Arduino Uno R3’s usb firmware updated. It was a pain in the butt. I connected these two pins.
http://forum.arduino.cc/index.php?topic=88022.msg679869#msg679869
I had to run the dfu-programmer command multiple times one immediately after the other in order for it to honor the command.
Well done. It was a two minute job for me. Wonder why there is a difference.
Figuring that Mac is the closer of the two to Linux, I downloaded 1.94 and tried it out. After the thing acted idiotic for a bit, it finally started tracking the coordinates and letting me reset the coordinates to 0. It is 2:13am, so I will leave the full test for tomorrow.
@Justin_Adie the pictures that I saw had insruction for uno R1. I had to look for the uno R3 instructions and pins to connect. The biggest probpem was that it refused to admit the thing was there. I eventually found the rapid fire technique which I think I saw somewhere else for arduino related flashing. Maybe the Linux software for flashing was just not at the point it should have been at. I am also using Fedora which often means I am running old versions of software too.
Oh. In the port selection in Chilipeppr, I selected ‘grbl’ instead of ‘default’ for the arduino selection. It just made sense.
For sure you need to use grbl otherwise you don’t get the position data fed to you by sjps.
@Justin_Adie it took me a little bit to notice the option. I am not used to seeing it. I have no idea what the default is either.
There should have been some red text suggesting that you did so.
The default is for plain serial I believe.
Let us know whether you are getting decent results now @NathanielStenzel
Thanks!
@Justin_Adie Nope. My results are still sucking. I did adjust my program to remove some of the excessive lines though. That will reduce the chance of a buffer issue happening. I could try to make sure that the gcode always has X,Y,Z coordinates on each movement line but considering the fact that it seems to be going to positions not specified, that seems less likely to work. It may be that the execution of gcode was too fast due to movement speed with excessive lines that it could not keep track of its position properly. I can try again and see if it still misbehaves still. It may be a grbl firmware issue in version 1.1f.
I decided to make this issue on the grbl project on github just in case it is a problem with grbl and as I described it, the gcode may actually have been a torture test. https://github.com/gnea/grbl/issues/181