I have written a perl program to optimize sandify pattern files. All my tests so far have had good results.
The program cuts out all back and forth motion along the edges of the table, eliminates all circling around the edges of the table, and forces shortest path around the table through 2 and 3 corners (3 corner paths are replaced by a single corner path). The result is usually greatly reduced pattern file size, faster drawing on the table because movement along the edge uses longest segment length (think acceleration/deceleration), excess motion is gone, and it’s a lot less boring to watch because the unproductive edge motion is greatly reduced. It will save wear and tear on the table mechanism as well. All this leaves the pattern on the table unchanged except the edges sometimes looks a little ragged because there’s little motion along the edges to clean it up.
This is the first thing I have ever written in perl. It took me less than a week to write it (after thinking about it for months and abandoning every idea I had in that time). All you need to do is install perl and run the program- that should be easy.
I used strawberry perl in windows, if that helps, and it was very easy to set up. I think the code will be usable in any recent Perl 5 install.
I ran into a couple patterns that contained some residual useless motion after running trimify. I found that a second run of trimify on the “clean” output file eliminated the residue. I then edited the program to make two full passes on the input pattern and it seems to work. I have yet to find any patterns that still contain any residue after running the new version of the program. The new program is called trimify2x.pl which you can grab here.
The new version now names the output file based on the input file name. if you enter “starz.gcode” the output file name will be “starz_clean.gcode”.
Unless someone finds a bug, I’m not planning any more changes.
Great! The two pass version probably only needs to rerun the edge trimming to eliminate the residue that comes from the first pass. I don’t think it’s necessary to run the corner trimming / substitution a second time.
Have you tried running trimmed files on your table?
That came from your creation- Sandify. I’ve played with all the settings, quite a lot…
One of the things that trimify2x enables is patterns made with very high cycle counts. It trims out all the crap that would otherwise make those patterns too long and boring to watch.
The first part of the trimify2x.pl strips out excessive motion along each side of the table. That leaves sequences of corner statements that the second part of the program tries to reduce to minimum. I have detected a flaw in the algorithm that minimizes corner to corner sequences. If the corners are designated A, B, C, and D, you can have sequences like ABA or AA or ABAAD, etc., in which there are duplicates and reversals that the current algorithm doesn’t recognize and treat appropriately. I’m reviewing it now to see what needs to be done to fix it.
I’ve only seen problem behavior in one or two pattern files- the program works for 99% of pattern files.