At 12:28 AM 9/17/2008, you wrote:
> I do production work and always need multiple panels to complete a
> job. So there is no point to putting more than one board on a
> panel.
If that's what you do, why do you need to panelize it yourself? Just
ask the fab to make N boards and let them fit them to their panels as
best they can. They know how much space to leave between them for
V-scoring or tab routing.
You are mistaken about that. The fab house does *not* know what the
assembly house needs. The assembly house has equipment that puts
limitations on the panels. I specify the panels to suit the fab
houses I use, so I pick the panel size and the spacing.
However, panelizing at the pcb level gives you access to all the
standard tools for your panel, though, like BOM and X/Y output for
pick and place, panel-level drill reports, panel prints, fab drawings,
etc. It also lets you add alignment holes, margin notes, margins,
etc.
That is what I am talking about. This should be supported in PCB for
panelized designs without requiring that you copy and paste the
circuit N times.
The BOM and XYRS output should *not* be panelized. The Fab drawing
should be at the board level with notes about the panel. Global
fiducials can be useful and that is one of the things missing in
FreePCB. But I don't see how using a script is required to add
support for these things.
My point is that whatever is provided for panelized designs should
make use of the panelization commands in the Gerber files. Gerber
files are large enough without increasing their size by a factor of
N. Drill files are different and do require specific entries for
each copy of the board.
Step and repeat panelizing means that EVERY tool and report needs to
know what the step and repeat factors are, and need to implement a
step and repeat feature within them. That's a waste of effort and
prone to errors.
What tools are we talking about? I am not at all familiar with PCB,
but if it is not an integrated layout tool, then I don't understand
the process.
> Other than the width of the rout around the board,
Which is exactly what I'm talking about.
The width of the rout and the board spacing are two different
things. In addition to the routs, you need to allow for the web
between the boards. This has to be wide enough to provide
support. That is something that has to be specified uniquely for
each design since the board size and shapes are different.
> My goal is to automate as much as possible and to eliminate any sort
> of manual work, including running script files.
If it's scriptable, you can automate it. You can't reliably automate
pointing and clicking, and with our type of panelization, you can
store the whole panel in source control as-is and not need to
re-panelize it (or remember your panelization settings) later.
Maybe I'm not following. I'm suggesting that the panelization be
integrated into PCB rather than use a separate tool. If this
scripting tool is editing the PCB design file, then it has to "know"
about the PCB file format and be kept up to date with any
changes. Editing the Gerber files makes it an independent tool, but
it is still a separate, extra step that has to be done and verified.
How is the panelization info stored in source control? Are you
editing the script specifically for each design and so have to store
it? Why not just make it a part of PCB and have the info stored in
the source file in the first place?
> That's great. But for straight forward work of building a panel of
> the same board repeated, there is no point to using scripts when the
> layout tool should produce the Gerber files for you.
Should? For someone who wants to take the risk of errors away from
humans, you're relying on them too much. A script can be automated
*outside* the scope of the layout engineer's access. The group
responsible for panelizing and fabbing should do that post-processing
by a smart script which knows the panelizing rules, not by one of many
layout engineers.
I don't understand what you are saying. The engineer has to spec the
entire design. That includes the panelization. Why can't that be
part of the PWB layout process rather than a script that has to be
run post layout? I certainly don't see how using a script is less
error prone. If the engineer is specifying the panel, how does that
get into the script?
> For the work I do, I need tools that facilitate productivity and
> minimize the risk of errors. I prefer to use tools that do the job
> simply and effectively without unnecessary manual steps. I think a
> step and repeat option should be in any good layout tool.
If you feel that strongly about it, go ahead and add it. I wrote a
panelizer. You can panelize using a pcb script. There's at least one
other panelizer. No reason not to have more. You can even store the
panelizing parameters in the pcb file as board-level attributes if you
want. Heck, write a plug-in for managing those parameters, and add a
hook in the gerber exporter to read them and add the line you want.
That's where the power of open source comes in - if you don't like it,
you can change it, and everyone benefits.
That is exactly why I am looking at departing from FreePCB. Although
it is "open source", there seems to be one developer and no
reasonable way to share code modified/created by others. When I wrap
up my work on this project I will be taking a good look at other
tools including PCB. If I decide that I need to use it and it does
not support panelization, I may just do the work. But right now I am
trying to understand what has been done and the reasons for it.
If I were a layout engineer at your company, I'd want to keep my board
in a source control system, and use some internal web server to submit
it for panelizing (the server reads the board from source control,
avoiding the risk that the layout guy submits an uncontrolled file),
rather than even consider doing it myself.
Submit it to what??? The layout person (me) has to specify the
layout parameters. I don't understand what you are trying to protect
the process from? I think that there are parts of this that I don't
understand and you have not explained.
Rick
_______________________________________________
geda-user mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
