Skip to content

Releases: aersida/GCodeClean

v1.4.2 - Migrate to .net v9 - fix a nasty little bug from v1.4.1

08 Jul 06:38
7692b1d

Choose a tag to compare

Main change in this release was to upgrade everything to .net v9

And also to fix a small but very annoying bug I introduced in v1.4.1 (i.e. the previous release)

What's Changed

  • Make folder bolt to make instructions easer to follow by @BarbourSmith in #36
  • Upgrade to .net 9.0 fix introduced bug by @aersida in #38

New Contributors

Full Changelog: v1.4.1...v1.4.2

v1.4.0 - Restructure before new work

20 Feb 00:01
7e67096

Choose a tag to compare

A restructure of the overall solution before starting some new work.

Mainly separating out the 'actions' (clean, split and merge) into their own project, instead of leaving them with the 'CLI' project.

Improved `merge`, now 'depth of cut' aware

10 Jan 04:30
4980b45

Choose a tag to compare

Description

The Travelling comment generated by the clean command has been restructured. It now identifies a 'sequence', which is a new set of cutting paths for each tool change. This is on the assumption that each tool change is deliberate and meant to be at that point in the GCode. Then within that it allows for 'sub-sequences' which are relevant to the split and merge commands. There's also been some minor bug fixing.

The split command aggregates the various cutting paths identified by each Travelling comment into 'sub-sequences' depending on the maximum cutting depth. This becomes part of their respective file names.

The merge command orders all of the files by the 'sequence' and 'sub-sequence' parts of their names, and reorders each 'sub-sequence' on its own. And then merges all of the files back into one reordered file.

`merge` 🎉

29 Dec 03:39
e0c33d0

Choose a tag to compare

The BIG One

This release adds in the merge command, which is the compliment to split.

merge takes the output of split, which is a folder containing individual files for each cutting action, calculates a 'better' way to order those cutting actions to reduce the travelling distance, and then merges all of those files back into one.

Also changed is the License, from MIT to AGPL.

And also changed is the library I used to handle the command line inputs. Which leads to ...

A proper single executable that actually works.

v1.2.0 - File Splitting

03 Dec 06:29
e0a517f

Choose a tag to compare

Description

And now the new function split is implemented.

This will let you take a previously cleaned GCode file, and split it into individual cutting actions, each one its own discreet GCode file.

This function is a key precursor for doing 'travelling' optimisation, i.e. solving (or at least being better at) the "Travelling Salesman" problem of optimising a cut.

Handle a changing context everywhere

28 Jul 07:42
aa51d8c

Choose a tag to compare

Description

It was all supposed to be so simple ...

As I was running through some tests (using a particularly nasty bit of GCode) I noticed that certain curves (from linear to arc deduplication) were scrambled, although most of them were fine.

And down the rabbit-hole I fell.

This particular nasty bit of GCode used multiple coordinate planes, so not just G17, but G18 and G19 also. Why? Really bad CAM programming I suspect, from the looks of what it was used for.

However, while GCodeClean has the maths to support this, I never really got it working, simply assuming that there would only ever be one coordinate plane in use for a whole file.

So now that I have the preamble context in a really sweet spot, I could get each function that needed to know the coordinate plane to define an initial context, and then update that line by line (of GCode) to always have the correct coordinate plane with which to feed into the processing. Hey presto 🎉 , linear to arc dedup suddenly works properly for all coordinate planes.

But that left another issue (cover your children's ears for this one), it's totally legal to change units in a GCode file, going from inch to mm and back again. Why anyone would want to do this is beyond me (utter perversity I'm guessing), but 'supporting' this abomination was 'the right thing to do' with regard to making the code cleaner and sticking to the NIST spec. So here it is...

Sometime soon I'll add a guard to detect the length unit change in the GCode, and have it connect to all bluetooth speakers in the vicinity getting them to scream obscenities at maximum volume, oh and also crash out the GCode clean up.