Closed brainstorm closed 6 years ago
Hélio, Roman! Sorry but I'm not abetusk nor know the refereed project. Best regards Ricardo
Enviado do Yahoo Mail no Android
Em Ter, 6 6e fev 6e 2018 às 6:56, Roman Valls Guimerà&It;notifications@github.com> escreveu:
Hello @abetusk, I reached your project through a thread on KiCad forums.
I tried to compile as shown in the README, but:
$ ./cmp.sh
gerber_interpreter.c:280:10: warning: implicitly declaring library function 'isspace' with type 'int (int)' [-Wimplicit-function-declaration]
if (!isspace(op))
^
gerber_interpreter.c:280:10: note: include the header ~~~~~~~~~~
/Library/Developer/CommandLineTools/usr/include/c++/v1/tree:2454:14: note: in instantiation of member function 'std::1::map_value_compare<Gerber_point_2,
std::1::value_type<Gerber_point_2, int>, Gerber_point_2_cmp, true>::operator()' requested here
if (!valuecomp()(root->value, v))
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/tree:2383:20: note: in instantiation of function template specialization
'std::1::tree<std::1::value_type<Gerber_point_2, int>, std::1::map_value_compare<Gerber_point_2, std::1::value_type<Gerber_point_2, int>, Gerber_point_2_cmp,
true>, std::1::allocator<std::1::value_type<Gerber_point_2, int> > >::__lower_bound~~~~~~~~~~
/Library/Developer/CommandLineTools/usr/include/c++/v1/tree:2384:26: note: in instantiation of member function 'std::1::map_value_compare<Gerber_point_2,
std::1::value_type<Gerber_point_2, int>, Gerber_point_2_cmp, true>::operator()' requested here
if (p != end() && !value_comp()(v, *p))
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/map:1220:68: note: in instantiation of function template specialization
'std::1::tree<std::1::value_type<Gerber_point_2, int>, std::1::map_value_compare<Gerber_point_2, std::1::value_type<Gerber_point_2, int>, Gerber_point_2_cmp,
true>, std::1::allocator<std::1::value_type<Gerber_point_2, int> > >::find~~~
/Library/Developer/CommandLineTools/usr/include/c++/v1/map:1349:44: note: in instantiation of function template specialization
'std::1::tree<std::1::value_type<Gerber_point_2, int>, std::1::map_value_compare<Gerber_point_2, std::1::value_type<Gerber_point_2, int>, Gerber_point_2_cmp,
true>, std::1::allocator<std::1::__value_type<Gerber_point_2, int> > >::find_equal
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
@brainstorm, Thank you for the bug report and for trying out gbl2ngc!
I'm using a Linux distribution and I think you're running into some differences between the g++
compiler on OSX from my system.
I believe the issue is that the comparison function I'm using wasn't declared const
. On my system this doesn't generate a compilation error but maybe the OSX compiler is pickier. I've updated the function in question (the operator()
method in the Gerber_point_2_cmp
struct) and have confirmed it still compiles and works on my system.
This might require a little few back and forth, if you're willing, to make sure the fix corrects the issue and to work out any other errors that might occur.
Regardless, I would try grabbing the latest source and trying to compile again. I would appreciate letting me know if there are any more issues or if it was successful.
Thanks @abetusk! It did compile with your changes after removing the linker's -lboost_thread
flag.
Unfortunately my KiCad board does not seem to be parseable with your gerber parser:
$ ../src/gbl2ngc --input breakouts-B.Cu.gbl --output test.ngc
PARSE ERROR: unknown image parameter code at line 1 '%TF.GenerationSoftware,KiCad,Pcbnew,(2017-10-17revision537804b)-master*%'
Please have a look at https://github.com/brainstorm/gbl2ngc/commit/82093e3c00bf8ba2892233b9b73c99a27d797d3f for more details and an example, thanks for writing this software ;)
@brainstorm, for what it's worth, I extended gbl2ngc
to parse (and ignore) the failing lines (the TF
etc.). I tested it on the file you pointed to and it seems to work fine. If you'd like to test it out, please feel free and let me know if you run into any more errors.
I didn't add your example file breakouts-B.Cu.gbl
because I wasn't sure if it was something you wanted shared in this repo. I would be happy to accept it and add it to a (now non-existent) test suite to try and catch errors in the future. If you'd like to issue a pull request, I'd happily take it, so long as you update your repo with the latest.
It would also be good to get some type of conditional compilation so you didn't have to hand tweak the compilation script. Maybe it's time to move to a makefile or something more exotic.
Just so you know, the current parser is incomplete and will fail on some Gerber features that haven't been implemented, such as aperture macros and circle arcs. Hopefully I'll get to implementing these sometime in the future, especially now that I have some sample Gerber files to test against.
Sure! Please add my example in there, no worries ;)
Yesterday I had to resort to FlatCAM to get things done(tm). But since I'm seeing that you are rekindling development of this neat little tool, it would be great to have those GCodes supported as close as possible from FlatCAM outputs:
https://mega.nz/#F!qkJgybhD!b3Frag1qgZpu4sKHPOe0SQ
Those are from the same .gbr mentioned before. Those GCode outputs above worked surprisingly well for this little SMD breakout board. With some more G-Code based autolevelling (candidate feature to add into your code?):
http://www.autoleveller.co.uk/
I bet the results would be just perfect :)
@brainstorm, could you formalize what it is you want and maybe open a few issues? For example, is it the GCode at the beginning and end that you would like to see added?
Also, would it be possible to use your SMD files as a test? The one in your fork looks to only be pads with no connections.
In terms of autolevelling, I built some tools a while back to do some simple "GCode forming" based off of a uniform grid of samples. The one that uses Catmul-Rom interpolation can be found in my abes_cnc_utilities repository.
While I'm not opposed to autolevelling, it seems a little 'tacked on' in terms of this tool. It might be better to update something like grecode rather than extend this tool.
What do you mean by SMD files? Here's the full KiCAD project, feel free to use all those files in any way or form you wish (including more flatcam-generated G-Codes as example):
https://mega.nz/#!n8ZV2AaA!ks5VlRxgdJi_Y_Xct82e5UiAlXZYZu_63IhFlx3sLFk
My objective is to have a CLI/automated toolchain to mill my boards as fast as possible, with the least amount of UI clicking and adjusting parameters around possible. This is why I highly appreciate your software and its potential.
This is also why I just successfully ported FlatCAM to a more modern/supported state via this pullrequest:
https://bitbucket.org/jpcgt/flatcam/pull-requests/75/initial-port-to-python3-and-pyqt5/diff
So that, at least, I can have a local toolchain on my laptop that does not require windows.
Also, auto leveling is rather crucial feature (for me) since our CNC mill will not produce valid PCBs otherwise, see:
https://bitbucket.org/jpcgt/flatcam/issues/72/z-profile-feature#comment-43324228
I totally see your angle though, small tools that can be easily combined as in the good UNIX philosophy. It would be quite rad if your small tools could be combined in such a way!
Anything works for me as long as it's as automated as possible. I hope my intentions are clearer now :)
@brainstorm , for what it's worth, there's a good page on the RepRap Wiki about different Gerber to PCB milling options. In particular there's the command line tool pcb2gcode that is mature and has a community around it. I believe it even has autoleveller functionality (see their manual for details).
One of the reasons I created gbl2ngc was because pcb2gcode renders to a picture and then converts to gcode, which introduces many small 'jaggies'. Presumably this isn't a problem for "everyday" use but that was the motivation to create this tool, so that the geometry could be translated in a more direct way.
Thank you for the example project, I'm going to add it in the next update.
Considering pcb2gcode has an autoleveller, maybe it's fair game to add it. Do you have any thoughts on what kind of autolevelling you would want for non-uniform grids?
And how is the CLI version of FlatCAM going? Is it something you're happy with?
Yes, I've tried pcb2gcode before but I became quite jaded with:
1) The ton of dependencies it requires (as packaged nowadays in OSX's brew).
2) Kilometric commadline arguments instead of .rc
/config files (I might have missed this possibility in the docs?).
3) UI-centric instead of CLI/API focused.
4) Not updated for newest KiCad gerbers fileformat.
Here's my summarized experience with it:
$ pcb2gcode --zsafe 10 --zchange 10 --zwork=-0.05 --offset=0.1 --software mach3 --drill fab/breakouts.drl --front fab/breakouts-F.Cu.gbr --outline fab/breakouts-Edge.Cuts.gbr --output-dir mill --dpi 1000 --metric true --cut-feed 250 --mill-feed 600 --mill-speed 1000 --zcut -1.56 --cutter-diameter=3 --cut-speed 12000 --cut-infeed 0.5 --zdrill -1.6 --drill-feed 1000 --drill-speed 10000
Importing front side...
** (process:58701): CRITICAL **: In file fab/breakouts-F.Cu.gbr,
unknown RS-274X extension found %TF%
(... many CRITICAL errors after...)
DONE.
Processing input files... libc++abi.dylib: terminating with uncaught exception of type Glib::FileError
Abort trap: 6
I might report this issue, but as per the points above, I wanted something a bit more lightweight/modern like you seem to be aiming at with your project. Glad to hear you are not losing precision either, that image transformation process you mention does seem problematic.
FlatCAM's CLI is a bit confusing with all that TCL layer... I haven't tried it yet because I was getting the tests passing first, but as far as I saw in the code, they seem to be in the middle of some kind of migration with it, so not totally convinced it'll work reliably.
I don't know, I think I would love to have something I could just call from KiCAD like Eagle does, I'll see.
Thanks for the RepRap wiki reference too!
Ha, it looks like they ran into exactly the same issue I did. I think the Gerber specification has been updated to include new fields and so all the tools that haven't been updated in a couple of years have started breaking.
I'm still updating gbl2ngc
with arc support, aperture blocks and aperture macros but if your Gerber files don't use them, gbl2ngc
might be usable for you now.
If you wouldn't mind, please let me know how things turn out with you. Please feel free to email me if you'd like to take this discussion off of the issue tracker.
My current bottleneck is indeed autolevelling, boards look good-ish but they are clearly not leveled in one side making them useless, I really need that feature for a functional toolchain.
No idea on non-uniform grids levelling, I would probably start looking at bCNC's autoleveller since it looks relatively advanced.
Sure, feel free to reach me at: brainstorm at nopcode dot org.
Hello @abetusk, I reached your project through a thread on KiCad forums.
I tried to compile as shown in the README, but: