Grbl Controller 3.4 Released

I did a push the last couple of days and fixed a few issues and added new features to the latest Grbl Controller 3.4. Currently available for Windows, Linux and Raspberry Pi.

Next up – working on Qt5 compatibility.

Enhancements
- Z-axis slider now allows rapid control of Z-axis positioning. This feature is still
  being evaluated for proper behavior due to some user-interface issues.
  If you run into trouble, please report a bug.
- All axis control buttons have been permanently enabled regardless of whether or not an
  axis command is in progress – this allows more rapid updating. Note – there is no error
  checking for the case of entering too many commands for the Grbl buffer. This is unlikely
  but possible.
- Now supports setting of baud rates from 9600 to 115200
- Aggressive preload enabled is now the default. If the user upgraded from an older
  Grbl Controller and had it disabled, a popup will warn them that it is being enabled.
  They still have the option to disable, if desired
- Logging is turned on by default (only for new installs)
- All detected errors are collected and displayed after a file is run in the status view
- If filtering unsupported commands, all commands filtered out are listed after the file
  is run.
- Logging now gives the line number of each command sent from the file and the corresponding
  ok or error also contains the line number.
- An option has been provided to reduce the precision of lines that exceed Grbl’s line buffer,
  which by default is 50 characters. The code removes the arguments with the greatest precision
  first and ending with at least one decimal place of precision. Errors are generated if it
  cannot remove sufficient precision for the available buffer space. The buffer size on Grbl
  is configurable in the options, as older Grbls have 50 characters and newer have 70.
Bug Fixes
- If Grbl stops responding (waiting for an ok), Soft Reset Grbl now functions correctly
  (so you can soft reset without having to restart Grbl Controller). This affects aggressive
  preload mode only.
- Commands to start/stop coolant coupled with dwell commands and aggressive preload cause
  Grbl’s modal logic to stop sending OK responses (on purpose). This was solved by waiting
  for the OK of the coolant off before sending additional commands. It is not clear whether
  this fixes all possible such modal problems, so use carefully and report any anomalies.

Grbl Controller supports the AlaMode in version 3.3.8

I’ve fixed a problem with Grbl Controller where it expected Grbl to reset upon serial port open – some devices like the AlaMode initialize once and when you connect, there is no version response. The fix involved sending a Ctrl-X if no response was detected.

The AlaMode is an Arduino-compatible board that stacks on top of the Raspberry Pi and communicates serially through the GPIO bus.

Checkout my writeup on getting the AlaMode running with Grbl

You can pick one up at MakerShed

Grbl Controller 3.3.5 Released with optimal Grbl detect upon COM port open

Due to a problem a user was experiencing with connecting to non-Uno arduinos, I have modified the Grbl version detect code to no longer send out a linefeed upon connect. Now the code just waits for a response from Grbl upon connection.

Since my last posting on Grbl Controller, I have also made some modifications to the visualizer – it now handles pretty much any kind of valid gcode.

Also, when sending a file, you can now choose to send each line as-is or have Grbl Controller filter it based on what is supported on Grbl 0.8. This setting is in the options dialog.

Minor fixes to Grbl Controller 3.3.1 Visualizer

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.

Grbl Controller 3.3 Released

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:

http://zapmaker.grblcontroller.s3-website-us-west-2.amazonaws.com/

Enjoy – and send me feedback!

Aggressive Preload – what the?

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:

  1. 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.
  2. 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…

Grbl Controller 3.2 released

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.