This doesn't answer any of your questions, but Mark Roszko did some
refactoring of gerbview that had some really nice changes. I believe he
started the refactoring with the intention of switching gerbview over to
GAL.
https://github.com/marekr/kicad-devel
Jon Neal
On Tue, Feb 14, 2017 at 1:38 PM
Hello Clemens,
Why not have one _database_ in between schematic and layout and
> manufacturing, assembly (and ERP and ...) and the tools just pick what they
> need?
I agree that this is the better option. But it is also an ambitious
project. For example, for machine assembly, the global database
On Tue, Feb 14, 2017 at 09:26:21AM -0500, Wayne Stambaugh wrote:
> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release? If not, I will set the version string and tag that commit as
> 4.0.6. How much time do our source translators, doc devs, and library
> devs need to
There are no large items outstanding for the libs, can be tagged at any
time.
On 15 Feb 2017 01:30, "Wayne Stambaugh" wrote:
> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release? If not, I will set the version string and tag that commit as
> 4.0.6. How much time d
Hi all,
I want to get familiar with the GAL codebase, and it occurred to me that it
might be fun to play with porting GerbView to GAL. I know it is on the 6.x
roadmap, but it seemed to me that it would be mostly not dependent on any
other changes that I see on the roadmap or have seen people talk
Hi,
I think Konstantin's icons are a more complete and homegenous set -
I'd rather see those go in first. If there is still any use for my
icons after that, I can rebase on top of that.
He and I have talked about rebasing his branch into a simpler set of
smaller patches (eg. just zoom icons) for
Hi Wayne,
John metion that his changes are on the tip of this branch:
https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons
Also, would you please be so kind to include this icon in attachment. I
have some problem is generating the patch for it.
thank you
Fabrizio
On Tue, Feb
Here are some approaches I know about (some of these available in KiCad
today, some of them not until tomorrow :-)
- Splitting up the part into logical blocks as Mark said
- Depending on user preference / company policy, using component attributes
to map all power and ground pins rather than show
Your patch has been merged into the master branch. Thank you for you
contribution to KiCad.
Cheers,
Wayne
On 2/11/2017 1:31 PM, Jon Evans wrote:
> Hi,
>
> Minor patch to eeschema attached to fix reported issue with clarify menu.
>
> -Jon
>
>
> ___
Where do we stand on this? I think these changes should be committed.
If there are no objections, please send a patch to the dev list so I can
merge it.
On 2/10/2017 4:37 PM, John Beard wrote:
> Hi,
>
> I have a few tweaks to some icons in Pcbnew and Eeschema. These are
> mostly minor tweaks tha
OS X will be faster this time, probably 2 days or fewer once
everything is ready from libs and docs.
Adam Wolf
W&L
On Tue, Feb 14, 2017 at 8:26 AM, Wayne Stambaugh wrote:
> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
> release? If not, I will set the version string an
Are there any outstanding issues to prevent rolling out a 4.0.6 stable
release? If not, I will set the version string and tag that commit as
4.0.6. How much time do our source translators, doc devs, and library
devs need to have everything ready?
Thanks,
Wayne
_
You split up the one part into multiple blocks with common
functionality grouped the same way you may have a U9A and U9B of a
logic IC with two gates. You'll just use quite a few pages
___
Mailing list: https://launchpad.net/~kicad-developers
Post to
Hi,
just for fun/information from the (german) news:
http://www.elektroniknet.de/markt-technik/halbleiter/details-zu-power9-138554.html
The Power9 Processor Family has internally 2359 Signals, 7370 Power (10
different voltages) and 9909 Ground-Pins.
This is of course (not yet) on board level, b
Hi, Thiadmer!
On 2017-02-14 12:21, Thiadmer Riemersma wrote:
> And as others have already observed: a BOM tools sits in the middle of
> workflow.
I agree here!
> The software to prepare our pick & place machine has a BOM editor.
> Our ordering/inventory system has a BOM editor too.
> So what I
On Tuesday 14 February 2017 11:47:52 Clemens Koller wrote:
> Hello, Martin!
>
> Your work looks very promising.
> I am running very similar stuff "manually" (by executing .sql scripts)
> around my commercial tool.
>
> Is there an ODBC in between your frontend code and the Firebird database
> you us
Hi,
On 14.02.2017 10:54, Strontium wrote:
> I believe it would be far preferable for these types of components
> simply to define the functions of each pin in a table, and then when
> placing the part, its just an empty box (like a nested sheet). You then
> right click on the part select "Add pi
I think it would be nice if the symbols were actyally dynamic, in the sense
the the pin funtion is selectable interactively in eeschema, instead of
syncing it with an extetnal db. The external db if implemented coukd ocf
still be used to generate this dynamic symbol, in theory.
Den 14/02/2017 11.4
Hello Oliver,
One option that I would like is to have a column with package names, rather
than (or in addition to) footprint names. So that
Capacitor_SMD:0805_Handsoldering becomes simply 0805. That is easier for
the stock management and ordering process.
And as others have already observed: a BO
Hello, Martin!
Your work looks very promising.
I am running very similar stuff "manually" (by executing .sql scripts) around
my commercial tool.
Is there an ODBC in between your frontend code and the Firebird database you
use?
I am asking because the data here sits in a MariaDB storage.
Regard
Hello, Stromtium!
Thank you for your heads-up!
I fully agree here and can't resist to "think big" and motivate when we are
planning to support some future design entry methodologies in the long term.
Today, we already have:
400++ configurable Pins of a FPGA
+ 300++ muxable Pins of a CPU
+ 300+
Oliver,
Thats does sound fantastic, and it should be incorporated into kicad, in
my opinion, because its not just a BOM Tool, it would be component
management with BOM export and is complimentary to external BOM tools
not a replacement for them.
Steven
On 14/02/17 18:08, Oliver Walters wrot
I actually like this idea and can relate to the problem. Basically
having "optional" pins, still retaining the alternate pin function though.
These are some hefty changes to the current implementation, but having
the .sweet file system consider this might be an idea, so that this may
be implem
Steven,
I am currently playing around with this idea, actually. I'm converting the
layout from a wxGrid to wxDataViewCtrl which allows each "group" to be
expanded (to show which components are contained therein) and many other
advanced features.
This may turn into more than just a BOM tool.
On T
This looks really nice, this would be awesome if it allowed you to edit
the BOM as well, for example, your line 3, change 0.1uf to 1uf and C1,
C7, C8, C9, C10 and C16 all change their value in the schematic to
match. Obviously there are things you wouldnt be able to edit, such as
Reference and
Can I make the suggestion, for CPU/MCU/FPGA type parts that have lots of
configurable pins, drawing an actual component is tedious and somewhat
pointless as its just a box (or multiple boxes, one for each subunit)
with pins.
Some CPU's have so many functional units and pins that fitting it all
No, we don't really use sign-off's, but you added it to your patch.
2017-02-14 10:35 GMT+01:00 Clemens Koller :
> Thanks!
>
> Do we actually collect "Sign-offs" of the devs/authors for KiCAD?
>
> And - I forgot: There are similar locations in the code with could run into
> the same issues.
> I di
Thanks!
Do we actually collect "Sign-offs" of the devs/authors for KiCAD?
And - I forgot: There are similar locations in the code with could run into the
same issues.
I didn't / couldn't check these.
Regards,
Clemens
On 2017-02-13 23:33, Chris Pavlina wrote:
> Thank you both. I pushed the f
28 matches
Mail list logo
