To clarify, I agree fully that critical functionality should be core. Extra
functionality could be available via an exposed scripting interface, which
I suppose is already available via the existing python framework.
On 23 Aug 2017 14:55, "Wayne Stambaugh" wrote:
> On
To assist compilation of a set of rules, we might be able to use this link to
my effortson loading/saving an Eagle DRU file. I've listed all the settings
saved by the Eagledesign rule check dialog, and annotated the output file. I
list the equivalent DRU keywordwith its associated dialog entry
On 8/23/2017 8:49 AM, Tomasz Wlostowski wrote:
> On 23.08.2017 14:05, Wayne Stambaugh wrote:
>> This is the missing piece of the puzzle. We would need to create a
>> constraints manager to handle a list of constraints which could either
>> be an internally defined constraint or a custom python
On 23.08.2017 14:05, Wayne Stambaugh wrote:
> This is the missing piece of the puzzle. We would need to create a
> constraints manager to handle a list of constraints which could either
> be an internally defined constraint or a custom python constraint.
> Without a well defined interface, this
On 8/23/2017 7:32 AM, Oliver Walters wrote:
> Something I have been considering for a while - instead of hard coding
> complex DRC rules into base code, what if we developed a DRC API and
> write the rules in Python?
I can see using python for complex or custom constraints but not for
general
I have experience in python DRCs and have a background in ASIC layout software
and Design Rule Checks as well as a healthy experience in GIS and layer
manipulation..
I have started KiPadCheck exactly to fill in some missing (IMHO) DRC checks. It
might be a good as a base for further
On 8/22/2017 5:33 PM, Thomas Langås wrote:
> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh wrote:
>> I'm not opposed to this change. However, there are two schools of
>> thought when it comes to board layout: strict layout constraints and no
>> layout constraints. I
Something I have been considering for a while - instead of hard coding
complex DRC rules into base code, what if we developed a DRC API and write
the rules in Python?
Each rule could be a separate python file (similar to how footprint wizards
are done). Users could enable/disable each DRC and
If you're looking for good DFM manuals, check out protoexpress, otherwise
known as Sierra Circuits.
They're a professional board house in the USA with simple to complex board
design support including high speed interfaces, uvias, etc.
On Tue, Aug 22, 2017 at 2:33 PM, Thomas Langås
I have created KiPadCheck as a post-layout DRC addition to KiCad. It has some
checks related to pads, vias, drill, silkscreen, paste, and mask that address
some shortcomings in KiCad DRC. I have also researched Eagle's DRC and they
allow a fairly wide range of specifications for layers, vias
On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh wrote:
> I'm not opposed to this change. However, there are two schools of
> thought when it comes to board layout: strict layout constraints and no
> layout constraints. I tend to lean towards the latter but I've been
>
On 8/22/2017 8:05 AM, Bastian Neumannn wrote:
> Hi
>
>> Ultimately is it useful to design a board, if you cannot make it?
>
> Right now I can fabricate boards, I can not design. That is also not a
> good solution.
>
> via constraints are tricky bussiness as they are very specific to the
>
> On Aug 22, 2017, at 3:10 AM, Simon Küppers wrote:
>
> I second this. Working in a Research Institute I can assure you, that very
> often there are circuit boards with "interesting" stackups and via
> configurations... These boards are not produced by quick-turn
Hi!
Maybe, some of these HDI Design Guides + documents are useful:
http://www.we-online.com/web/de/index.php/download/media/04_leiterplatte/2011_2/relaunch/produkte_5/microvia_hdi/141030_DesignGuide_HDI_1_1.pdf
Page 8 gives quite a good overview of what's possible - at least!
Hi
> Ultimately is it useful to design a board, if you cannot make it?
Right now I can fabricate boards, I can not design. That is also not a good
solution.
via constraints are tricky bussiness as they are very specific to the
manufacturer.
> PS:
> The current "tracks and vias editor" dialog
Le 22/08/2017 à 12:10, Simon Küppers a écrit :
> I second this. Working in a Research Institute I can assure you, that very
> often there are circuit
> boards with "interesting" stackups and via configurations... These boards are
> not produced by
> quick-turn factories like eurocircuits but
I second this. Working in a Research Institute I can assure you, that
very often there are circuit boards with "interesting" stackups and via
configurations... These boards are not produced by quick-turn factories
like eurocircuits but companies such as ILFA or Optiprint.
It would be unwise
On 22/08/17 18:25, jp charras wrote:
Le 22/08/2017 à 05:55, hauptmech a écrit :
Manufacturing techniques vary between manufacturers and continuously evolve.
Why would kicad limit
itself to what eurocircuits can do? They have optimized their process for quick
turn prototyping and
while they
Le 22/08/2017 à 05:55, hauptmech a écrit :
>
> Manufacturing techniques vary between manufacturers and continuously evolve.
> Why would kicad limit
> itself to what eurocircuits can do? They have optimized their process for
> quick turn prototyping and
> while they document their process
Manufacturing techniques vary between manufacturers and continuously
evolve. Why would kicad limit itself to what eurocircuits can do? They
have optimized their process for quick turn prototyping and while they
document their process nicely, they are probably not a good reference
for what
Oh I did not realize that gmail does not reply to the mailing list, but to
you directly.
I know how the progress of creating boards work. I know that you can only
have symmetrical stackups.
What I don't know is why KiCad limits micro-vias to outer to first inner
layer only.
To know where
Le 20/08/2017 à 17:12, Bastian Neumannn a écrit :
> On the issue of layers and via types.
>
> The current system allows micro-vias from the outer to the underlying layer.
> blind and burried vias
> from the second to the second-last layer and regular vias through all layers.
> In my current
Le 19/08/2017 à 15:20, Bastian Neumannn a écrit :
> Ok so basically the dialog asking to change the sizes should come when you
> change the type in the
> dialog, not when you press OK?
Changing the via type is more tricky:
- One can use the net size as default when changing between micro vias
Le 18/08/2017 à 20:47, Bastian Neumannn a écrit :
> Hi,
>
> the last patch for this function was not correct I am sorry. This patch gives
> the correct
> functionality to notify the user when die via size is smaller than the
> minimum size given in the net
> class.
>
> Cheers
>
Hi Bastian,
Hi,
the last patch for this function was not correct I am sorry. This patch
gives the correct functionality to notify the user when die via size is
smaller than the minimum size given in the net class.
Cheers
From 07756c6c7d28aac83cf9ee7b0e087c8b6b09bd01 Mon Sep 17 00:00:00 2001
From: Bastian
25 matches
Mail list logo