Mail Archives: geda-user/2014/09/05/16:43:52
On Fri, Sep 05, 2014 at 03:11:04PM -0400, Jason White wrote:
> On Fri, Sep 5, 2014 at 2:48 PM, Bernd Walter <ticso AT cicely7 DOT cicely DOT de> wrote:
> >> I think zip would certainly be the most flexible path, that way you
> >> can keep the human readable layout files and include whatever fonts or
> >> images are required without inserting huge ASCII-encoded binary blobs
> >> all over the place.
> >>
> >> The tools and scripts would still work, all you'd have to do is feed them
> >> the text file from the zip.
> >
> > I consider this impractical if you regulary switch between text editor
> > and PCB.
> > And it completely breaks revision control systems without having a
> > specific ZIP plugin.
>
> I'm curious if that is a very common use case among gEDA users?
No idea.
But the file format is very well documented and much easier to get than
some of the UI features.
Counting number of elements?
Start PCB, export the bom, then count, or just:
[485]devel> grep '^Element' pcb | wc -l
560
This is also quite handy without the wc to get an overview about the
Element flags used - sometimes some unintended sneaked it.
Same for Via, Pins, Pads, ...
Sometimes the count is required to get an idea about manufactoring costs.
> I certainly spend a lot more time in the tool than the text editor.
Depend on which point in design I am.
I also spend most time in PCB for doing the layout itself.
However there are some points I prefer doing outside.
In many cases I don't knwo how to do it in PCB, or if it's possible at all.
Some examples:
Switch DRC setting for another board manufactorer, or optional higher
density feature set.
Just copy the DRC line is easy compared to go through all values by hand.
I do this a lot, as well as checking drawing properties.
Sometimes you switch if DRC clearance
There are a few I ocassionally change inside PCB, such as polygone clearance
or unique devicenames (for panelizing).
I do some automatic checks on wether those are in my default state.
I do all my footprint designs in text editor with PCB running at the
same time to visually inspect result (recent PCB versions detect newer file
dates and ask for reload).
The reason to do so is using exact locations and sizes is much easier in
the ASCII format than on screen, even became easier since PCB started
accepting mm values.
You can see if there are any changes at all before check in a new version.
Sounds simple, but in fact it has some strange dependencies.
For some time the crosshair position was saved, therefor it alwazs had
changes, then it started randomly reordering components.
There are many other things I do, such as mass updating flags and so on.
Now (20140316) it randomly switches some values from mm to mil and back:
[484]devel> svn diff
Index: pcb
===================================================================
--- pcb (revision 6621)
+++ pcb (working copy)
@@ -5845,7 +5845,7 @@
)
-Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 206.8805mm 37.7820mm 20.00mil 60.00mil 2 100 ""]
+Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 8144.90mil 37.7820mm 20.00mil 60.00mil 2 100 ""]
(
Pad[207.36mil 3.7498mm 241.34mil 3.7498mm 11.02mil 30.00mil 14.02mil "1" "1" "square,edge2"]
Pad[207.36mil 127.95mil 241.34mil 127.95mil 11.02mil 30.00mil 14.02mil "2" "2" "square,edge2"]
@@ -7185,7 +7185,7 @@
)
-Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 206.8805mm 89.2170mm 20.00mil 60.00mil 2 100 ""]
+Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 8144.90mil 89.2170mm 20.00mil 60.00mil 2 100 ""]
(
Pad[207.36mil 3.7498mm 241.34mil 3.7498mm 11.02mil 30.00mil 14.02mil "1" "1" "square,edge2"]
Pad[207.36mil 127.95mil 241.34mil 127.95mil 11.02mil 30.00mil 14.02mil "2" "2" "square,edge2"]
> I somewhat curious about your work flow. Do/can you branch and merge
> PCB designs like source code? Are you using some external scripts to
> generate features in your boards?
I do branches, but merging almost always has to be done manually.
Very often i start project by reusing an existing layout, because a
new project just differs in some peripheral area.
Some of the unrequired part is wiped out by editor, some by PCB.
Sometimes the diffs help to distribute changes in common parts,
but it still is a lot of work.
The switch from pure mil values to mil values made it harder, but
I consider this a one time switch.
One of the most uncommon branch I do is for pogo pin adapters.
I branch the PCB file, remove all vias and wiring.
Then I add pseudo vias where I want pogo pins, where I have tooling holes,
at which positions the board has bare surface and can be pushed down
on the pogo needles, ...
Then I save, remove temporarily all components and export the drill
file, which is for the "vias" only, since I removed the components.
This is all done in PCB, but whenever my design changes I can easily
update the Elements in the pogo branch and handle the changes.
This can be done within PCB as well, but if done outside I can see
what changes there are and if I (for whatever reason) I missed something.
And I don't have to grab the mouse for that.
> What about treating directories as files like the Netbeans IDE does
> with its projects? Then optionally compressing them into a zip.
> That would make it play nice with just about any version control
> program while still allowing portable designs.
--
B.Walter <bernd AT bwct DOT de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
- Raw text -