I’ve posted a new Windows build of 3.1.1 on the S3 site. A user found a problem with computer-generated gcode that is conforming but Grbl Controller did not handle correctly in the Visualizer – i.e. it would not process spaces between an axis and value, so g0 x 0 y 0 wouldn’t work, but g0 x0 y0 would. This is now fixed.
Two other fixes made: Last line was being dropped in a file and stray spaces in an empty line would crash Grbl Controller.
You asked for it, you got it – the Visualizer. Version 3.3 provides a view of the file being processed. It shows both the static image (in blue) and a live run-time image in green, indicating progress completed. The red dot is the last known reported position of the spindle bit.
Linux/Raspberry Pi users, clone it from github or Windows and Mac users can download here:
Enjoy – and send me feedback!
So I tried to mill some 1/4″ Lexan (Plexiglas) and had the feed rate a little too high. After running for a few seconds with chips flying all of a sudden the V-wheels and assembly of the Shapeoko started making these thumping noises.
Turns out that the Lexan chips that were thrown about were molten and landed on the Makerslide V’s and froze there, adding “speed bumps to the road”, as it were.
After carefully scraping off the Lexan chips with my fingernails, it runs like new.
Next: Add small vacuum hose on the spindle to prevent this in the future.
I decided to move my binary downloads off this site onto Amazon S3 to reduce potential traffic (after github decided to stop hosting binaries). I had about 300 downloads off github of the Windows Grbl Controller 3.0 installer exe, so this should help my site loading.
Thanks for your patience.
I had to come up with a catchy name for it. Here’s the story. On the Shapeoko forum a user (Joey) tried using Grbl Controller 3.0 and found that his nc file would “stutter”. I asked him for a copy and ran it through my tests – the problem was that the file had many line segments that caused an acceleration and deceleration for every segment, which would appear like a stutter effect.
Joey rightly pointed out that GCodeSender didn’t have this problem. I ran it, and sure enough, he was right, the accel/decel were gone, it ran fast and smooth. Why? The code in GCodeSender would keep sending commands to Grbl as fast as possible without waiting for an ok. The old Grbl Controller would always wait for an ok after every command. Turns out that Grbl is actually designed to accept a chain of commands and it will optimize the speeds between each command.
Now, Grbl has a limited input buffer of 128 bytes. It only takes about 8 or so commands before the buffer fills up. If you pull down the Grbl code off github, you will get a file called stream.py, which is a python script that precomputes how many bytes of data it has put into Grbl’s buffer at any given time and limits additional commands until it gets ok or error acknowledgements. You get an ok (or error) for each command, so it is really a simple problem to know when to send a command and when not to. Interestingly, the GCodeSender code does not do this computation – I am surprised no one is experiencing buffer overruns in Grbl when using GCodeSender (which happens to be written in C#).
Taking a cue from stream.py, I modified Grbl Controller to use the same approach to aggressively preload Grbl’s input buffer, without overflowing it. This had to be done in a way that also allowed the old approach to also function properly. I didn’t want to rewrite the serial logic, so it ended up being tricky to support both modes in the same code (normal and preload), but it is in there and working properly.
Thinking I had it working, I bumped up against a couple of problems:
- On fast PCs, the serial send would drop data on rare occasion. Unfortunately, this confused the preload counting logic and around half way through the file send it would just stop – because the expected number of ok’s didn’t match the actual. Turns out that QextSerialPort’s Windows library needed a minor tweak to increase the send timeout from 10 to 500 ms.
- The deluge of commands due to preload caused rapid redraw of the status window, which becomes slower to respond the more data in it. I was seeing the Raspberry Pi run a 4 minute file in 10 minutes due to CPU pegging. Fortunately I found a trick where you disable the window’s auto width computation and limit the number of “scroll to end”s and all of a sudden the performance was really good again.
And when I ran the tests, my preload mode would result in messed up cuts. Did I have a bug? No – my stepper shields’ bolt-on heat sink’s nuts had come undone due to vibration and the stepper drivers were shutting down due to overheating! Once I tightened them up, all worked well. Now I need to find that Loctite…
After getting bogged down in the subtleties of some new features and extensive testing, Grbl Controller 3.2 is finally released. Notable enhancements:
- Support for what I call “Aggressive Preload” – during a file send, sending as many commands as the input buffer of Grbl will hold. This uses the same kind of logic as the Grbl project’s stream.py Python script. The original, normal send-acknowledge is the default, the new preload approach can be enabled if desired.
- Z-rate limiting is now fully functional. Any Z-axis command during file send is throttled to the specified option value. Additionally, combined X-Y-Z commands are split into throttled Z-rate and X-Y are send immediately after separately with a feed rate also specified in the options.
- Logging has been greatly enhanced using the Log4Qt library (which mimics the log4j java library).
- Windows and Linux users now have a File > Exit menu. All menus now have accelerators.
- Optimized the status list view behavior to not bog down the system, particularly on slower Raspberry Pi systems. One downside is that there is no horizontal scrollbar, however, if you enable file logging, you can see all log information that way.
- Fixed a lurking problem with Windows builds (it probably never manifested itself previously but with preload, it showed up on a fast system) – the QextSerialPort library needed to be tweaked to not leave the serial send timeout at 10 ms, but was changed to a hardcoded 500 ms. This is because at 10 ms, sends would timeout and data would sometimes not be sent.
All other enhancements/bug fixes can be found in the README file on github.
Executable binaries have been moved from github to this site because github is phasing out binary download pages. You can find Mac and Windows binaries; Linux/Raspberry Pi binaries must be built from source.
I’ve found some time here and there and added some significant enhancements for V3.1. Most notably:
- Support for Grbl 0.8c
- LCD displays position obtained from Grbl, not computed from file/command
- Removed all cycling of COM port which was losing position information (among other issues).
See github README file for the full details.
Note – binaries are not yet available.