Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
AMParamStmt was not calling to_gerber on each of its primitives
on his own to_gerber method. That way primitives that changes after reading,
such as when you call to_inch/to_metric was failing because it was
writing only the original macro back.
|
|
We moved the functionality to cairo backend, it can write png and svg and maybe more (pdfs?)
|
|
|
|
I found out that Proteus generate some strange Excellon without any tool definition.
Gerbv renders it correctly and after digging in I found the heuristic that they use
to "guess" the tool diameter. This change replicates this behavior on pcb-tools.
|
|
When regions were the first thing draw there is no current aperture
defined, as regions do not require an aperture, so we use an zeroed
Circle as aperture in this case. Gerber spec says that apertures have
no graphical meaning for regions, so this should be enough.
|
|
Add some not so used codes that were generating unknown stmt.
|
|
|
|
Adds a loads() method to the top level module which generates a GerberFile or ExcellonFile from a string
|
|
Cairo render unification
|
|
This fixes the circular cutout issue described in #32. Regions were previously stored as a collection of points, now they are stored as a collection of line and arc primitives.
|
|
per #33
the issue was trying to re-open the temporary file. it works on everything but windows. I've changed it to seek to the beginning and read from the file without re-opening, which should fix the issue.
|
|
|
|
|
|
This branch allows a pure cairo based render for both PNG and SVG.
Cairo backend is mostly the same but with improved support for
configurable scale, orientation and inverted color drawing.
API is not yet final.
|
|
Add example demonstrating use of tsp-solver with pcb-tools to optimize
tool paths in an excellon file. This is based on @koppi's script in #30
|
|
remove dict itervalues() calls
|
|
ExcellonFile, such as getting a tool path length and changing tool parameters. Excellonfiles write method generates statements based on the drill hits in the hits member, so drill hits in a generated file can be re-ordered by re-ordering the drill hits in ExcellonFile.hits. see #30
|
|
eagle per #28.
|
|
Got a bunch of metric files with no MOMM but only G71, this
should be pretty mush harmless.
|
|
We now check if there is a %XXX*% command inside the line before
considering it a multiline statement.
|
|
ADDxxx param statements were too greedy on the mofidiers and were
matching more than it should in cases where there are no newlines after
the statement like:
'%ADD12C,0.305*%%LPD*%', in a single line. The '%' was not exluded form
modifiers so it got confused with the %LPD*% concatened.
top_copper.GTL example was changed to be in a single line now with no
spaces at all and it works well.
|
|
PCBmodE uses a standard but probably undefined behaviour issue
on Gerber where it defines circle apertures with a single modifier
but leaves a trilling 'X' after it. 'X' is modifiers separator but
when there is only one modifier the behaviour is undefined.
For parsing we are just ignoring blank modifiers.
Test updated to catch this case.
|
|
|
|
Fritzing uses more than 2 digits for tool in their Excellons. To comply
with that, I check specifically for 3 or less digits and use as tool
number, more than that we treat as the standard (2 for tool and 2 for
compensation index)
|
|
|
|
|
|
added units checking at the primitive level so the use case shown in the example is covered. Might want to throw a bunch more assertions in the test code (i started doing a few) to cover multiple calls to unit conversion functions
|
|
|
|
|
|
|
|
Based on code from @rdprescott.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FS D leading zero format (probably form Direct) is an unspecified
coordinate format where all numbers are specified with both leading
and trailing zeros.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add aperture macro parsing and evaluation.
|
|
|
|
|
|
All AM*Primitive classes now handles float for all but the code
modifiers. This simplifies the reading/parsing.
|
|
Aperture macros can get complex with arithmetical operations,
variables and variables substitution.
Current pcb-tools code just read each macro block as an independent
unit, this cannot deal with variables that get changed after used.
This patch splits the task in two: first we parse all macro content
and creates a bytecode representation of all operations. This bytecode
representation will be executed when an AD command is issues passing
the required parameters.
Parsing is heavily based on gerbv using a Shunting Yard approach to
math parsing.
Integration with rs274x.py code is not finished as I need to figure out
how to integrate the final macro primitives with the graphical primitives
already in use.
|