GPX releases: GPX 2.3, GpxUi 0.1.6 and OctoPrint-GPX 0.4
Mark Walker
Dan and I have fixed some bugs and added some new goodies to GPX and the OctoPrint plugin. (Hmmm... maybe a future release, I should sync up all the version numbers.)
How do I get it?
OctoPrint should offer to upgrade your GPX plugin automatically
For GPX on your desktop you can get it from the zip file here https://github.com/markwal/GPX/releases or if you have Windows, install it bundled with GpxUI here http://markwal.github.io/GpxUi/.
New experimental features
- EEPROM settings : Reading and modifying EEPROM settings directly from OctoPrint's UI.
- GPX macros: Also, I've added some new gcode macros that you can use in your start/end gcode.
- Right click in Windows Explorer: GpxUi adds a "Convert to x3g" on the right click menu for gcode files.
Both of the eeprom features are in beta/experimental stage so I recommend that you backup your EEPROM before giving them a whirl. The rest of the plugin and GPX, I consider to be in "stable" mode and this release includes several bug fixes. Particularly pertaining to cancel/abort handling.
I haven't added the EEPROM support to GpxUi yet. Anybody want it? For me, I'm just using OctoPrint for this.
Bugfixes
- Fix some weird pauses. OctoPrint expects to do a complicated call and response with the firmware because some firmware (Marlin) does out of order responses and expects the host to wait for an ok except when it doesn't. Unfortunately, this can lead to 30 second pauses if OctoPrint thinks it is supposed to wait. I've switched it over to being the simple case of always giving ok and telling OctoPrint to always expect it.
- M108 now works for a toolchange if it doesn't have an RPM parameter. Some versions of RepG do this and then someone also infected slic3r with it, if you choose Sailfish flavor gcode. This is incorrect since it isn't sailfish that causes this, it is using RepG to convert the gcode to x3g, so it'd be more correct to say it is RepG flavor rather than sailfish flavor, but hey.
- %LOCALAPPDATA% support on Windows GPX reads gpx.ini from %LOCALAPPDATA% if it exists. This will make a GUI setup easier.
- Allow wider range of values for digipot settings. Gpx constrained the digipot values, but so does the firmware. Removing the limit in GPX allows support of different digipots in the future.
- Support M1 for enhanced sailfish pause functionality. You can now insert an M1 into your gcode and gpx will generate an x3g pause.
- Support G28 without parameters to home all axes correctly. It was there before but had a bug in it.
- And others
Coming soon
Hopefully. Assuming I get enough time to work on it. I'd like to make it so that OctoPrint detects when there is a new version of Sailfish available and will let you download it from the internet and flash it onto the bot directly from the OctoPrint UI.
More info on the new features and some pictures
Slic3r
You can use a link for slic3r's post processing script so that it doesn't break when you upgrade GpxUi. Someday I'll add something to the UI to set this up automagically, but for now put "c:/users/<yourusername>/appdata/local/gpxui/gpx.exe.lnk" (without the quotes) in the "Post-processing script" box. You can make sure you've got the right place by putting everything up to that last forward slash in the explorer address box and see if it takes you to the right place.
EEPROM settings
Some of the EEPROM settings are a first for UI of any kind. That is, though the firmware supports the settings, ReplicatorG didn't show them. For example, you can now change the sense of just one of your endstops (for example, if you would like switch one to an optical sensor).
Right click
And right clicking on a gcode file in the shell (when GpxUi is installed) looks like this:
The new macros include:
(@build <NAME>)
Sets the build name that is displayed in build statistics on the LCD
(@flavor <FLAVOR>)
The gcode itself can indicate whether it is MakerBot or RepRap flavor.
(@load_eeprom_map)
Checks your firmware flavor and version and loads up a matching eeprom mapping table (maps names to addresses). Currently only Sailfish 7.7 is supported because that's all I can test easily.
(@eeprom <NAME> <TYPENAME> #<ADDRESS> [<LEN>])
Defines a custom eeprom mapping of type <TYPENAME> from <NAME> to <ADDRESS>. If the <TYPENAME> is 's' for string <LEN> indicates the eeprom space available for that string (max length + 1).
(@eread <NAME>)
Reads eeprom value and displays it to the console or writes to the log. In OctoPrint it'll return to the terminal window.
(@ewrite <NAME> <VALUE)
Write eeprom <VALUE> to location indicated by <NAME> in the current mapping table (either loaded by @load_eeprom_map or defined by @eeprom).
(@debug [pos]|[axes])
Asks the bot and/or GPX a question and display the result to the console/terminal window/log. Current supported questions are pos which will ask the bot for its current position and axes displays GPX's current understanding of the axes definitions (steps/mm, maximum feedrate, etc.)
Be sure to let me know about any bugs/issues you encounter on the github issue tracker.
Thanks and happy printing
Ryan Carlyle
Dan Newman
>
>
> Dan and I have fixed some bugs and added some new goodies to GPX and the
> OctoPrint plugin. (Hmmm... maybe a future release, I should sync up all
> the version numbers.)
was done by Mark. I've done some bug fixes, answered questions, and made
suggestions, but this wouldn't have been possible without Mark's hard work.
And I've very happy to provide some assistance.
Dan