Some of us are likely to end up paying for a subscription too on the basis that we use the tool enough for it to be reasonable for us to pay. ( so there’ll be opportunity for ongoing comparison )
My main concern would be the support load it would almost inevitably generate as users not familiar with running home brew or open source code used it on their GCode and ran into issues. If the loss of rapids is anywhere near as irritating as I expect it to be there will be quite a bit of demand and therefore quite a few issues.
re: support - It’s going to be super annoying, and I’m afraid that I won’t have time to properly support such a tool beyond some “here’s how to use it” video tutorials and the such. This supplementary post-processor is definitely not an ideal solution
re: subscriptions - That’s a good point. I suppose we don’t have to rush to get a dataset of gcode if there will be several members of the community who can provide test routines.
I’m most worried about some unsupported setup causing crashes, tool breakage etc.
Very easy to build and simpler than the other gcode tools I’ve build… if there is interest I can likely build something like this in about an hour or so
I’ve written and operated quite a bit of Python, so if it ends up as Python then I can help out with questions about running it, Python environments on Windows / OSX etc.
Count me in for beta testing (there is no question that there will be interest, lots of it).
If the Autodesk folks don’t change their mind (as they did on STEP export), I’m sure we’ll see TENS of similar scripts being created all over the globe, but there is value in having one that is known to work with files generated using the Shapeoko post-processor.
To be honest I already pictured this as one of the cool JS apps that @fenrus does, a simple page with a button to upload a set of files, that would spit out one file with tool change commands and rapids. A large “use at your own risk blablabla” disclaimer, done.
The really interesting part will indeed be the validation of that code across a large dataset. I foresee some maintenance effort too, whenever the Fusion360 folks will change their post-processing back-end to “clarify” things further, and it happens to break the application in the process.
3 Likes
Griff
(Well crap, my hypometric precursor device is blown…)
7
I’m happy to help with any beta testing as well.
From the perspective of a non-nerd (said with all respect), I just need something that works, if it can be done wrong I’ll find a way type of user.
Many moons ago, I got really irritated that plunges from CC were emitted without rapid to a safe height (the previous Z) and plunge from there. So I set out to over engineer the problem. A lot. I wanted to try some Swift, and came up with a few things to otherwise optimize while I was at it (including implementing “/” and lay the groundwork for some better reordering to minimize rapids…the old traveling salesman problem)
I’m not going to claim this code is right, or useful, an even moderately poor example of swift code or even very helpful, but it’s here if someone has a want. I haven’t touched it in 4+ years.
at this point I have a lot of this kind of stuff as helper libraries in C++ and Javascript… porting also to python shouldn’t be insane since it seems that’s what folks want.
as part of a gcode optimizer I also have the library functions built that track the cutter engagement for a path (based on previous G1) so conceptually using G0 if the engagement is 0.00 is quite in the realm of possible…
… or if there is a “go up, move, go down” pattern, change the amount of up to the level just above where engagement becomes non-zero
I think I’m the one who kicked off the python thing, but it’s just the hammer I have- another language is fine, I just won’t be as effective for helping develop. At the end of the day we’re all just into it to make the problem go away
@julien a JS app is long term totally the way to go-upload a few nc files and just download the corrected result. In any case it looks like fernus is pretty experienced at this so that’s a fantastic starting point
I’m going to collect a few dozen projects off of Winston’s patreon as test input, plus make a few test programs that are more likely to cause trouble. I’ll share that work after getting permission from Winston for his work.
@griff we’re a group of people who make programs from 3D models to move a drill around and cut cool shapes in wood. If that doesn’t make us all nerds I don’t know what would
I would love to have some relatively simple design create gcode that shows the problems…
(a 5 megabyte gcode file is less useful there than a relatively simple one)
Thats strange, I just checked with some test pieces and they had no difference in posted gcode (as tested by diffchecker - also saw some G0’s floating around in there)
EDIT: just kidding! I changed a few parameters in my test design back and forth and now we’re posting bad gcode.
The attached gcode is a simple test file I put together for this purpose. The model (see: dropbox link) is a box with a cutout and a joined sphere in the interior. I apply a number of redundant adaptive and pocket operations with a few different settings to it in order to exercise the full extent of badness that we could have reasonably expected fusion 360 to have thrown at us before having seen it.
It looks like at the start of each toolpath, F360 does the following
G0 {entry point}
G1 {clearance height}
{retract height}
{feed height}
{normal toolpath stuff}
We can use this to identify the clearance, retract and feed height for the toolpath, and then just keep track of where F360 moves to, changing toolpaths as needed.
I am not into writing scripts, so I don’t know if this is useful. but it is something I stumbled upon while looking for a solution for another problem* I have: https://cam.autodesk.com/hsmposts
And from the ‘Manual’ button:
This may not apply so I apologize if it doesn’t contribute to the solution…
*For the curious, the problem I am researching and trying to solve has nothing to do with scripting to replace or re-enable the rapids, but instead with exporting operation ‘edit’ parameters, specifically I would like to output all parameters and current values for a given operation to a spreadsheet for archiving/comparison. Basically everything that is enterable in the multi-page windowlet when you go to edit an operation, I want to output all of those things to a spreadsheet…
