Grbl Controller 3.0 released

[zapmaker]

I've rewritten the old Grbl Controller from the ground up and released version 3.0. Included in this version is the first native Mac OSX release (64 bit C++ code), plus a special installer that supports the old 32 bit Intel hardware (10.5). To use on the Mac you will need to also install the Mac FTDI drivers. Grbl Controller supports the Mac, Windows and Linux (Ubuntu and Debian). A list of the latest enhancements can be found in the README file on github.

A few sites you may want to check out:

Shapeoko Wiki, Grbl Controller: http://www.shapeoko.com/wiki/index.php/Grbl_Controller

My Grbl Controller home page (i.e. what was my motivation for this two month, any spare minute, undertaking): http://zapmaker.org/projects/grbl-controller-3-0/

Installers for Grbl Controller on github: https://github.com/zapmaker/GrblHoming/downloads

FTDI USB COM port drivers (find Mac drivers here): http://www.ftdichip.com/Drivers/VCP.htm

Installing USB COM port drivers on Windows http://arduino.cc/en/Guide/windows

Hope you find this new tool useful.

[rpe]

I download and installed it but I am in the process of adding a 2nd Y motor. I like the enhancements very much. I will let you know if I have any problems with it.

[bobt]

Zapmaker - I have installed QT 5.0 on my Raspberry PI under Raspbain (latest). I am downloading your code to build it on that box. I intend to use my Raspberry PI as the front end to my ShapeOko as a start. By the way my Raspberry PI is the same size as my Ardunio. So just make the box a little taller to have it all.

Bob Teeter

[AngusF]

I quite like your version of Grbl Controller. I've got a request, though: Manual reset instead of automatic, please! I've got two arguments in favour of that change: First, I'd like to disable automatic reset on my Arduino. Second, when I finish a job, I'd like to be able to maintain my existing zero point without having to go back and find it again.

This bit of G code will zero the coordinates without needing to reset the whole Arduino:
G92 x0 y0 z0

As a further request to that, would it be possible to offer customization of the zero point? For example, if I was to use a precisely machined spacer block to find zero plus 20mm, I'd need to send G92 x0 y0 z20.

Thanks for all of your hard work on this program. I've tried a few Java-based G code senders, and they all stop working as soon as I turn on my spindle. I'm not sure why your program doesn't, but I'm sure grateful for it!

[AngusF]

A second request - Can it pause and bring up a popup when it encounters a tool change?

Thanks!

[zapmaker]

Yes, 'go to home' is high on my list. I took it out because the original code didn't move the tool up off the work-piece and didn't have time to put in a suitable fix. The other points you make are valid.

Also, if there are any Qt Desktop programmers out there, I am looking for collaborator(s) on this project on github. I'm thinking that would help turnaround time for features and fixes.

Glad you like it. I'll post when an update is ready.

[bobt]

zapmaker - Just to let you know I have gotten your code to build on a Raspberry PI with raspbain. I am working up the list of what I did and in which order to do them. I currently trying to solve a tty problem on the PI. It sees the the initial output of the grbl card and does see the first command but after that it locks up. I have used the screen program to talk to the card and it works fine. So I am looking at the serial port configuration to see what is different between Grbl Controller and screen. I just loaded some .deb files and scp'ed your code from my windows box which got your code with git extensions and was not modified or built on my windows box. I builds fine. So now to figure out the terminal interfacing stuff.

Bob Teeter

[zapmaker]

Bob - I'm impressed that you got it to run on the raspberry pi, I didn't even think of that as an option!

I've seen lockups before in the code and almost 100% of the time it was due to one thread stomping on the data of another due to incorrect/non-existent data protection. There is a chance you uncovered such code that, for some reason, isn't manifesting itself on the other platforms. I did hammer on the code pretty well on all three platforms, but multithreaded issues can be difficult to reproduce quickly. I understand that this may not be a multithreaded issue and could be something specific to the pi.

Regarding multithreaded coding, every dialog in Qt is run in a separated thread, additionally, I've fired off some threads to do various work. Now, I'm lazy as far as implementing critical sections/mutexes when I don't have to, and Qt has an architecture that allows you to almost avoid all use of the multithreaded primitives if you use their signal/slot model of inter-thread communication, which was the approach I chose. It is possible I didn't catch all conditions.

When you set an atomic variable, i.e. an integer - CPUs do the set in one instruction, so the set does not need to be protected. Example in GrblHoming code would be Gcode::setShutdown(). This sets shutdownState = true, and is a direct call from one thread into another with no protection (vs. signal/slot), but that is ok, since it is an integer. If the code said shutdownState++, that would need to be protected with a critsec/mutex, because that compiles down into multiple assembly instructions. That is the kind of thing that I am looking for - a call from one object to another directly that is not an atomic operation.

I'll take a look and if I see any issues during connection with the controller, if I find anything I'll let you know.

zapmaker

[cvoinescu]

If the code said shutdownState++, that would need to be protected with a critsec/mutex, because that compiles down into multiple assembly instructions.

Wouldn't it need to be protected even if it compiled into a single instruction? Another core could still access that memory.

[zapmaker]

To some degree you are correct. If you know that a particular operation is truly atomic, then you can get away with this. An example where it probably wouldn't work is if you try to write a 64 bit value on a 32 bit processor. This is explained by visiting the following link, here is the quote (notice the note about embedded processors, could the pi qualify here?):

Some hardware does not support efficient atomic updates to certain scalar objects. Another thread trying to concurrently read that value may only see half the update. This is less common now, but is believed to be an issue for some embedded processors. It is certainly an issue for large scalar objects,such as 64-bit integers on 32-bit hardware.

http://www.hpl.hp.com/personal/Hans_Boe ... r-faq.html

Fortunately, the affected code is small in Grbl Controller. I'll add locking to these methods for the next release, just so there are no questions. And it looks like I now have a reason to purchase a raspberry pi