Something else that i remembered now.
Would it be a good idea to prepare for alternative function handling for
pins?
Meaning an alternative pin name connected to an alternative type (or a
number of these)
That would allow better symbols for micro controllers.
I do not expect this to be
On 04/01/19 15:10, Wayne Stambaugh wrote:
Is there a way to mark a unit as "power unit" (I think you mentioned
sometime back that this might be required to properly make simulation
for multi unit symbols possible while still allowing the power unit to
be separate. A power unit would also be a
Tom
Thank you so much for the offer!
My code is here: https://github.com/BrianAtDocumentedDesigns/RenumKicadPCB
It needs to be seriously reworked in order to incorporate into Kicad because of
the way it works.
I read in the project sch, pcb, and netlist files. I scan the PCB file and
create a
Will do! Thanks for the advice.
I have a general idea about buttons, etc., from a basic knowledge of HTML but
Wxwidgets sure seems to permeate Kicad.
The good news is I have solved the geographical annotation problem before so it
is more a question of implementing it in a manner
On 04/01/2019 18:51, Brian Piccioni wrote:
> I am still keen to attempt to incorporate geographical component annotation
> into KiCad. In general, it is preferable for component annotation to be done
> relative to the PCB and in some logical order (left/right, top to bottom,
> etc). Thereafter
On 04/01/2019 03:14, Alex Lockwood wrote:
> I know this is solidly within in realm of minor complaints, but I
> wonder, is there anything "easy" that can be done about this?
>
> https://misc.c4757p.com/fuzzy-wires.png
Hi Alex,
It's a common artifact in MSAA (which was designed for games, not
Hi Brian,
If you don't have experience with c++ and GUI code in general I would
suggest you start by familiarizing yourself with wxwidgets framework that
KiCad is built on
http://wxwidgets.org/docs/tutorials/
A lot of KiCad code will make more sense once you understand GUI threading
and event
Am 2019-01-03 23:09, schrieb Seth Hillbrand:
Am 2019-01-03 22:42, schrieb Alex Lockwood:
Ah, clearly I didn't do a very great job of looking for bug reports.
Thank you.
I wonder whether we could switch to a different antialiasing scheme,
or
tweak this one? The antialiased fonts on my system,
John,
AFAICT, this fixes the issue so I pushed your patch.
Thanks,
Wayne
On 1/4/19 9:11 AM, John Beard wrote:
> Hi Alexis,
>
> Sorry about that - it's been on my list for a while. I misunderstood
> how the GAL inits without config. Hopefully this will work. Patch
> attached: the upshot is
Simon,
On 1/2/19 8:39 PM, Simon Richter wrote:
> Hi Wayne,
>
> On 02.01.19 23:20, Wayne Stambaugh wrote:
>
>>> This would be an artificial unit for the file format, not necessarily
>>> the true internal unit (which I want to unify across the entire program
>>> as soon as feasible, but that
I'm willing to add properties which are already defined to pins. There
has been talk about adding about adding electrical constraints for
advance ERC testing to symbols but that will not be part of the v6
implementation of the new file format. It's going to be a lot of work
to implement the
I'm willing to add properties which are already defined to pins. There
has been talk about adding about adding electrical constraints for
advance ERC testing to symbols but that will not be part of the v6
implementation of the new file format. It's going to be a lot of work
to implement the
Seth
Thank you so much for the prompt response and encouragement.
For those who are unaware, when a board is being debugged you typically look at
the schematic and need to find the relevant component. If the PCB is numbered
geographically this is much easier to do than if the board simply
On Jan 4, 2019, at 10:51 AM, Brian Piccioni wrote:
>
> I am still keen to attempt to incorporate geographical component annotation
> into KiCad. In general, it is preferable for component annotation to be done
> relative to the PCB and in some logical order (left/right, top to bottom,
> etc).
Am 2019-01-04 12:51, schrieb Brian Piccioni:
I am still keen to attempt to incorporate geographical component
annotation into KiCad.
This could be an interesting feature. I'll be keen to see what you come
up with.
The first thing I want to do is to add the ability for eeSchema to
import a
I am still keen to attempt to incorporate geographical component annotation
into KiCad. In general, it is preferable for component annotation to be done
relative to the PCB and in some logical order (left/right, top to bottom, etc).
Thereafter this information is imported to the schematic. I
> Now if you create a unique part number for every
> resistance value, tolerance, temperature coefficient, manufacturer, etc.
> that would be tens if not hundreds of thousands of unique part numbers.
I know my intervention may be a bit offtopic, but it may add some other
elements to discussion:
Yes you are right Wayne,
Its just that i believe an IDF like protobuf would ease the development
of such a feature/file-format, the tools around such a feature and allow
for a better overall iteration of such a feature/fileformat.
That is why i even mentioned it here, because since we are
Hi Kristoffer,
On 1/4/2019 10:24 AM, Kristoffer wrote:
> On 2019-01-04 15:03, Wayne Stambaugh wrote:
>
>> I can somewhat see the utility in this but it really doesn't make a lot
>> of sense to me. Lets assume for a second that it would be useful to
>> create a separate atomic part for every
On 2019-01-04 15:03, Wayne Stambaugh wrote:
I can somewhat see the utility in this but it really doesn't make a lot
of sense to me. Lets assume for a second that it would be useful to
create a separate atomic part for every 0603 resistor part number
currently available. Given that the 0603
Hi,
I have worked out how to do unit tests of the Pcbnew code.
The first example test is a pretty unexciting one about the import
plugin manager (which is what I was doing at the time).
This is followed by a fix for a minor 5.1 bug with a unit test on the
logic (numbered NPTH pads in arrays)
On 1/2/2019 8:24 PM, Rene Pöschl wrote:
> I have a few questions regarding multi part (or multi unit) symbols. (I
> do not really see a clear indication for these features in your document.)
>
> Is there a definition for having only some units exchangeable?
This is provided by the extends
Hi Alexis,
Sorry about that - it's been on my list for a while. I misunderstood
how the GAL inits without config. Hopefully this will work. Patch
attached: the upshot is that legacy should never even be tried in a
blank-config startup now, even if the platform supports it (as this
will be the
On 1/2/2019 2:55 PM, Vesa Solonen wrote:
> kristoffer Ödmark kirjoitti 2.1.2019 klo 12.32:
>
>> I would rather have a new atomic file-format or storage format, so one
>> could actually send a complete part in an easy way, that would include
>> 3D-Files, SPICE data, symbol and footprints, and it
Sorry - forwarding to the list. That's what happens when I do emails too late!
-- Forwarded message -
From: Andrew Lutsenko
Date: Fri, Jan 4, 2019 at 12:50 AM
Subject: Re: [Kicad-developers] [RFC] Symbol library file format
To: John Beard
Sorry, link to github:
25 matches
Mail list logo
