I've been using Path to GCode in both IS 0.92 and 1.0 with some success, but I hit a snag.
In my last efforts, I noticed my plotter repeating every curve twice. Looking at the gCode all paths are indeed being duplicated.
The code is making a second pass, but not increasing the 'depth of cut' - I think the problem might be due to me changing my system default from python 2 to 3.
In gcodetools.py - the stepRange is being calculated as:
for step in range(0, 1 + int(math.ceil(abs((zs - d) / self.tools[layer][0]["depth step"])))):
For python 2, with my current settings, this evaluates to 0 to 1 (I think the / is integer division on python 2, and this changed in python 3) For python 3, with my current settings, this evaluates to 0 to 2, so I get a second pass over all my curves.
This appears to be a problem using 'Pass by Pass' but not 'Path by Path' - so there is one workaround.
Another is to change the default (what I assume is the default) orientation point Z value to 0.
I had a brief look at debugging, testing this and maybe making a PR, but python is not one of my main languages, and I didn't see enough to get started writing a test for the a fix. If anyone can point me at some instructions for testing extensions, I'd take a look at making a fix?
In the mean time, I have python 3 and only 1 of each curve, so I'm happy.
I have been facing the same issue for the past two days and it was driving me nut as I tried all possible options I could think of ... Very glad to see it's not a problem with my setup! :)
Thanks you for posting the solutions, however need some more help,
Where/how do you change 'Pass by Pass' from 'Path by Path' for solution 1? - sorry if it's a dumb question, I have no knowledge in Python etc.. For the second solution, are you talking about z-surface (default 0.00) or z-depth (default -1.00)?
I found the calculation for number of passes was correct when I changed the cutting order in the dialog to 'Pass by Pass' (see figure) - no need to change any python code.
I ran into the same problem and came here. While Mike's solution worked for me, I chose to fix it in gcodetools.py as well while I was mucking about in there trying to fix another problem I had (Z-values being reversed, so also to do with the cutting order).
What strikes me as strange in the script, is that on line 3956, right after the option 'subpath by subpath' is handled, that option is changed to 'path by path', which makes it go through that condition code as well. Just commenting out that line solved the problem for me:
# self.options.path_to_gcode_order = 'path by path'
It would help if this extension had more comments from the developers, because right now its workings are pretty hard to understand (for me at least). It will require some more testing to see if my fix doesn't break some other functionality.
I'm available to mentor and anwser generic questions about extensions (and python) but gcodetools itself is somewhat unmaintained, which means there may not be anyone who knows why something works the way it does.
(see the red parts in this coverage report) We currently only cover 24% of gcodetools, BUT your one line patch drags the test coverage down to 19%, Is suspect whatever feature that option enables is a hefty 5% of the code.
Getting a few tests in actually sounds like fun. I had a good time figuring out these problems anyway :-) Gcodetools.py is quite complicated and like we said, it really needs commenting, cleaning up and testing, but I think I'll give it a go.
The reason the coverage went down might be that less code is run now with default arguments, right?
@Jaap Correct! default arguments are now not running as much code. This might be correct. So adding new arguments into the tester can improve the coverage.
I've been using Path to GCode in both IS 0.92 and 1.0 with some success, but I hit a snag.
In my last efforts, I noticed my plotter repeating every curve twice. Looking at the gCode all paths are indeed being duplicated.
The code is making a second pass, but not increasing the 'depth of cut' - I think the problem might be due to me changing my system default from python 2 to 3.
In gcodetools.py - the stepRange is being calculated as:
For python 2, with my current settings, this evaluates to 0 to 1 (I think the / is integer division on python 2, and this changed in python 3)
For python 3, with my current settings, this evaluates to 0 to 2, so I get a second pass over all my curves.
This appears to be a problem using 'Pass by Pass' but not 'Path by Path' - so there is one workaround.
Another is to change the default (what I assume is the default) orientation point Z value to 0.
I had a brief look at debugging, testing this and maybe making a PR, but python is not one of my main languages, and I didn't see enough to get started writing a test for the a fix. If anyone can point me at some instructions for testing extensions, I'd take a look at making a fix?
In the mean time, I have python 3 and only 1 of each curve, so I'm happy.
Many thanks
I have been facing the same issue for the past two days and it was driving me nut as I tried all possible options I could think of ... Very glad to see it's not a problem with my setup! :)
Thanks you for posting the solutions, however need some more help,
Where/how do you change 'Pass by Pass' from 'Path by Path' for solution 1? - sorry if it's a dumb question, I have no knowledge in Python etc..
For the second solution, are you talking about z-surface (default 0.00) or z-depth (default -1.00)?
Thanks again for posting this!
I found the calculation for number of passes was correct when I changed the cutting order in the dialog to 'Pass by Pass' (see figure) - no need to change any python code.
Good luck.
Thank you Mike! I tried it and it works as expected. I won't have figured it out...
Thanks a lot!!
What's the second method by the way?!
Hi,
I ran into the same problem and came here. While Mike's solution worked for me, I chose to fix it in gcodetools.py as well while I was mucking about in there trying to fix another problem I had (Z-values being reversed, so also to do with the cutting order).
What strikes me as strange in the script, is that on line 3956, right after the option 'subpath by subpath' is handled, that option is changed to 'path by path', which makes it go through that condition code as well.
Just commenting out that line solved the problem for me:
It would help if this extension had more comments from the developers, because right now its workings are pretty hard to understand (for me at least). It will require some more testing to see if my fix doesn't break some other functionality.
@plotterDanny If you've got a patch for the gcodetools.py I'd be interesting in reviewing it. You can post it here or at https://gitlab.com/inkscape/extensions/
I'm available to mentor and anwser generic questions about extensions (and python) but gcodetools itself is somewhat unmaintained, which means there may not be anyone who knows why something works the way it does.
Hi Martin,
Thanks. I submitted a merge request. I hope this is the right way to propose a patch (I think this is the first time I did this :-).
If this works out, there is another issue in the same file I would be interested to work on: #271
I just got a message the pipeline has failed. Is that because there are no tests written into the script?
Best wishes,
Jaap
Thanks Japp, I've commented on the merge request. If you're able to grapple with the test suite, then I think you will find fixing 271 easy enough.
Also, feel free to add tests too, the gcodetools.py is suffering horribly from under-testing, it's our worst script by a country mile:
https://inkscape.gitlab.io/-/extensions/-/jobs/662381448/artifacts/htmlcov/gcodetools_py.html
(see the red parts in this coverage report) We currently only cover 24% of gcodetools, BUT your one line patch drags the test coverage down to 19%, Is suspect whatever feature that option enables is a hefty 5% of the code.
https://plotterdanny.gitlab.io/-/extensions/-/jobs/667988782/artifacts/htmlcov/gcodetools_py.html
Hi Martin,
Getting a few tests in actually sounds like fun. I had a good time figuring out these problems anyway :-) Gcodetools.py is quite complicated and like we said, it really needs commenting, cleaning up and testing, but I think I'll give it a go.
The reason the coverage went down might be that less code is run now with default arguments, right?
@Jaap Correct! default arguments are now not running as much code. This might be correct. So adding new arguments into the tester can improve the coverage.
Hi all
The simple and shortest solution is to remove 1 from the following line in the file gcodetools.py.
for step in range(0, 1 + int(math.ceil(abs((zs - d) / self.tools[layer][0]["depth step"])))):
Well, after editing it should look like this:
for step in range(0, int(math.ceil(abs((zs - d) / self.tools[layer][0]["depth step"])))):