The approach with "power" components sounds like a really good way to handle
this (I think that should be put into the documentation as a tip). I always
felt power flags a hack, thanks for the confirmation. ;)
In a design there are not so many places where you provide power and there are
not so
I agree with Andrew's approach. Power flags are just a hack to suppress
a valid error message. If there's a power flag on a net ERC will still
be happy even after you accidentally delete the component that actually
supplies the power.
On 02/06/2016 06:14 PM, Andrew Zonenberg wrote:
It still w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It still works if you adopt the approach fully. I make separate
components "POWER_INDUCTOR" etc that have one terminal a power input
and the other a power output.
On 06/02/16 09:55, André S. wrote:
> This may work when the output is directly connected
We’re not talking about forbidding hiding pins, as far as we’ve reached in this
discussion we’re curently on giving a warning when setting a warning when a pin
is set to hidden.
And we are talking about the DRC giving to warn about multiple net names on one
net.
Nothing of this should make an
I could edit it without any problems with the 3.5.1-rc1 Windows version.
So I guess the file is OK and it is some problem with at least the OS X version
of 3.5.1-rc1.
> On 06 Feb 2016, at 23:47, Chris Pavlina wrote:
>
> Blame Mark, I used his wxfb :)
>
> I'll have a look a bit later. I haven't
Blame Mark, I used his wxfb :)
I'll have a look a bit later. I haven't done anything weird to that file.
On Sun, Feb 07, 2016 at 11:44:03AM +1300, Simon Wells wrote:
> Ok, not with that one i am tempted to blame chris as he is the one
> who has been messing with that file lately
>
> On Sun,
Ok, not with that one i am tempted to blame chris as he is the one
who has been messing with that file lately
On Sun, Feb 7, 2016 at 11:27 AM, Bernhard Stegmaier
wrote:
> It does seem to work somehow in general, but not an all files.
> Could you try on dialog_eeschema_options_base.fbp?
> This
It does seem to work somehow in general, but not an all files.
Could you try on dialog_eeschema_options_base.fbp?
This one doesn’t work at all for me.
Regards,
Bernhard
> On 06 Feb 2016, at 22:55, Simon Wells wrote:
>
> I have used the lastest osx binary from sf.net many times with no
> issues,
I have used the lastest osx binary from sf.net many times with no
issues, The only thing i have found occasionally is i have to double
click on the dialog in the left box to have it show up, but whether
this is a bug or a "feature" i don't know
On Sun, Feb 7, 2016 at 9:04 AM, Bernhard Stegmaier
w
Thanks, I’ll try to get Marks fork running on OS X for future use.
Accidentally, I just got a hand on a windows laptop.
The 3.5.1-rc1 really is usable on Windows… so much for being cross-plattform… :)
At least for the files I need I could check and generate the code with it for
now.
Regards,
Be
+1 to this, this is the only one that's been working properly for me lately...
On Sat, Feb 06, 2016 at 07:44:14PM +, Jon Neal wrote:
> Mark Roszko forked wxFormBuilder to make building much easier and faster +
> has at least one new wxWidgets widget.
>
> https://github.com/marekr/wxFormBuilde
Mark Roszko forked wxFormBuilder to make building much easier and faster +
has at least one new wxWidgets widget.
https://github.com/marekr/wxFormBuilder/
On Sat, Feb 6, 2016 at 2:30 PM Garth Corral wrote:
> Hi, Berhard.
>
> Yes this is a bit if a pain on OS X. I built this from HEAD sometime
Hi, Berhard.
Yes this is a bit if a pain on OS X. I built this from HEAD sometime last
year, and it seemed to work okay for my purposes. I had to munge a few things
to get it to build, though. I’ll send you a patch off-list and see if that
gets you going in the right direction.
It was some
Hi,
I manually made some changes to preferences dialogs which are working fine.
To finish this, I wanted to check that I didn’t break the .fbp files and
generate code from that (as it probably is supposed to be).
But, which wxFormBuilder to use?
Last official is 3.1.70, it doesn’t open at least
On 03.02.2016 07:33, Jeff Barlow wrote:
Actually I have intentionally located two footprints so they overlap.
Only one or the other (not both) are stuffed on a given board. One
board, two different BOMs, two different assembles. Very common trick.
Not really a DRC error. There needs to be a way
Then how is pcbnew supposed to know what's going to be connected?
I have not been using hierarchies much, is the nets separated?
-Original Message-
From: jp charras
Sent: Saturday, February 06, 2016 6:27 PM
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Discuss
This may work when the output is directly connected to the net.
But if you have some output/input filter behind it this will not work as
expected, you still need the power flag then.
André
On 06.02.2016 18:29, Andrew Zonenberg wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I do the s
Hi,
Am 04.02.2016 um 23:07 schrieb Chris Gammell:
> I was wondering if I could help out with the @kicad_pcb twitter account.
> I keep an eye on all things KiCad on Tweetdeck and noticed that the
> official twitter is rather dormant.
Speaking of social media: I've created a "KiCad" Facebook page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I do the same thing - power flags and hidden pins are banned in my
designs. To supply power to a net I set the "power output" flag on the
pins of the connector going to the battery/power plug.
On 06/02/16 09:23, André S. wrote:
> Ok, I see your point
Le 06/02/2016 18:12, Thor-Arne a écrit :
> I think the multiple netnames on the same net should be included in the
> roadmap v5 DRC check.
> This should as a minimum throw a warning as this might break the
> finished pcb.
Multiple netnames on the same net are a frequent case when using
hierarchies
Ok, I see your point regarding not breaking old designs.
However: the current KiCad broke mine, since it does regard hidden pins
different than "the old KiCad" (around 2013).
The old KiCad connected a visible "hidden pin" only to the connected net.
The current KiCad still connects it to "VDD" r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This sounds like the best option to me - keep the feature around but
throw a DRC error if you try to use it. This keeps old designs working
(albeit with warnings) and discourages use of hidden connections in
new designs.
Eventually, if the project rea
I think the multiple netnames on the same net should be included in the
roadmap v5 DRC check.
This should as a minimum throw a warning as this might break the finished
pcb.
It might also affect the hidden pins issue as one might have several supply
voltages connected to VCC pins.
However, it's
Any other OSX devs object to this being committed? Also, do we really
need to throttle on the other platforms? If not, I would rather not
have the ugly platform specific #ifdef/#endif code if we don't need it.
On 2/6/2016 10:25 AM, Bernhard Stegmaier wrote:
> Hi,
>
> attached a patch to disable
I would not have allowed that to be implemented. One thing I try to
avoid is forcing users down the "one true way" path of pcb design
whenever possible. I prefer to give users the flexibility to design as
they see fit even if it means that kicad has a steeper learning curve.
I don't pretend to be
Hi,attached a patch to disable the below mentioned FPS limitation on OS X.Without limitation/timer scrolling is smooth as expected.Even with heaviest scrolling or other use-cases I tested I did not observe any increased CPU load.At least, from a user perspective possibly drawing too often seems way
I agree with Chris on the hidden pins issue, old design should not be
broken.
When it comes to net names I think they should be forced to be unique.
Anyway, are we going to collect features requests now?
Would it be better to have a wanted-feauture list on github instead of the
mail list so no
Eh. I agree 100% about hidden pins being Bad, anyone using them surely should
be tarred and feathered. But I'm not sure it's our place to enforce good
schematic drawing practices. If people want to use KiCad to draw terrible,
horrible schematics, they'll find a way. Personally, I'm *strongly* again
Hi everyone,
this issues are still on my wishlist for KiCad:
- Ban hidden Pins.
- Disallow multiple labels on the same net.
Especially the combination of those two is a source for non-obvious
design bugs.
Wayne recently stated that now the planning for release 5 has started,
so I just thought
29 matches
Mail list logo
