Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 16.01.2017 13:41, jp charras wrote: > I am waiting for comments, especially for custom pads. Hi Jean Pierre, Many thanks for your comments. I need a bit of time to answer and rethink the proposal. I'll reply as soon as possible. Cheers, Tom ___

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

Le 16/01/2017 à 17:53, Wayne Stambaugh a écrit : > On 1/16/2017 10:30 AM, jp charras wrote: >> Le 16/01/2017 à 14:18, Kristoffer Ödmark a écrit : >>> For basic work, maybe reusing zones functionality in the footprint editor >>> will be enough, and then the anchors would be added by regular

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 1/16/2017 10:30 AM, jp charras wrote: > Le 16/01/2017 à 14:18, Kristoffer Ödmark a écrit : >> For basic work, maybe reusing zones functionality in the footprint editor >> will be enough, and then the anchors would be added by regular circular or >> rectangular pads. Similar to how one would

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 01/16/2017 04:30 PM, jp charras wrote: [snip] > Hi, CERN guys, > I remember someone at CERN worked on (or was willing to work on) SVG import. > > Is it a work in progress? Actually, the task has been undertaken by our friends from Brazil during the last hackathon. The basic import should be

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

>One constraint is the fact a custom pad shape (which can be build from a set >of basic shapes: lines, >circles, rings, polygon) is the fact the final shape should be only one >polygon (with holes). >Otherwise it is not *one* pad shape. >So all pad shape edition must be made from the pad editor

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

Le 16/01/2017 à 14:18, Kristoffer Ödmark a écrit : > For basic work, maybe reusing zones functionality in the footprint editor > will be enough, and then the anchors would be added by regular circular or > rectangular pads. Similar to how one would add custom paste layers today. > > For more

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

For basic work, maybe reusing zones functionality in the footprint editor will be enough, and then the anchors would be added by regular circular or rectangular pads. Similar to how one would add custom paste layers today. For more advanced, I vote svg or gerber import. SVG is a common file

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

Le 03/05/2016 à 14:40, Tomasz Wlostowski a écrit : > Hi all, > > Recently there has been a lot of discussion on these features. Here's a > short proposal how we could hit all three birds with one stone: > > Changes to SCH: > - none > > Changes to netlist import: > - auto_generate flag for SCH

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

A standard format for the text of a given field is not the same thing as adding code to the schematic editor to edit that field. I do not want to introduce code into the schematic editor for generating formatted field text for external use. This should be done within the current field editor or

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

If it's still too offensive, you could discard the naming part of my proposal and just modify the netlist format so that eeschema passes _all fields_ to pcbnew, that way the script can access them and do whatever it wants. It would enable all sorts of powerful things in the future, though it might

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

It would not introduce a limitation, just a standard format that would work with pcbnew footprint generators, external scripts can run outside of kicad and use field names and values however they please. On Wed, May 11, 2016 at 10:23 AM, Wayne Stambaugh wrote: > On

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 5/11/2016 10:24 AM, José Ignacio wrote: > What about (ab)using the footprint field (actually the library plugin > system) for this? Say you add a new library plugin called "python", > each library would be a python module (either a single .py file or a > folder with an __init__.py script) That

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

What about (ab)using the footprint field (actually the library plugin system) for this? Say you add a new library plugin called "python", each library would be a python module (either a single .py file or a folder with an __init__.py script) That module will have a callable for each "virtual"

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 5/11/2016 6:13 AM, Tomasz Wlostowski wrote: > On 09.05.2016 14:38, Wayne Stambaugh wrote: >> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote: >>> On 04.05.2016 16:48, Wayne Stambaugh wrote: How are you saving this auto generate flag and width/length parameters in the schematic? If you

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 09.05.2016 14:38, Wayne Stambaugh wrote: > On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote: >> On 04.05.2016 16:48, Wayne Stambaugh wrote: >>> How are you saving this auto generate flag and width/length parameters >>> in the schematic? If you are using component fields or text that's >>> fine.

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote: > On 04.05.2016 16:48, Wayne Stambaugh wrote: >> How are you saving this auto generate flag and width/length parameters >> in the schematic? If you are using component fields or text that's >> fine. However, please keep in mind that using component

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

Hi, On 03.05.2016 14:40, Tomasz Wlostowski wrote: > - net_tie: DRC treats the primitive as non-conducting and doesn't throw > a short circuit error (see drawing A) That requires the net tie to have a size that is at least larger than the minimum clearance of any of the netclasses involved. My

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

I'm 300% in favor of this proposal, an it makes sense to store the dimensions in the key_value pairs. From a user's perspective, they can grab a premade symbol with default values populated in those fields, place in the schematic and edit if necessary. for selecting the "autogenerated flag" what

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

On 04.05.2016 16:48, Wayne Stambaugh wrote: > How are you saving this auto generate flag and width/length parameters > in the schematic? If you are using component fields or text that's > fine. However, please keep in mind that using component fields and text > is for passing information to

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

The use of fields for arbitrary data is indeed powerful. It should also be limited to passing information to external tools such as simulators and scripts such as Tom's proposal. Anything that is supported as a feature in KiCad should be part of the schematic file format and fully supported by

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

How are you saving this auto generate flag and width/length parameters in the schematic? If you are using component fields or text that's fine. However, please keep in mind that using component fields and text is for passing information to third party tools that are not part of kicad. If we are

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

My 2c. One of the fantastically useful features of eeschema is components have an "arbitrary" list of key:value pairs (fields) attached to them as attributes. Can I suggest that such a feature attached to objects on the PCB would be even more powerful/useful. It would mean that changes

[Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

Hi all, Recently there has been a lot of discussion on these features. Here's a short proposal how we could hit all three birds with one stone: Changes to SCH: - none Changes to netlist import: - auto_generate flag for SCH components - when set, invokes a Python script/C++ plugin which updates