Thanks everyone for your input. I'll revert patch and move to creating the
IO_ERROR exceptions for unimportable items.
As an aside, is there a particular reason why polygons are not editable in
the footprint editor? Even if they were restricted to non-copper?
Regards
Russell
On Tue, Sep 26, 2017
Le 27/09/2017 à 12:20, Russell Oliver a écrit :
>
> Thanks everyone for your input. I'll revert patch and move to creating the
> IO_ERROR exceptions for
> unimportable items.
>
> As an aside, is there a particular reason why polygons are not editable in
> the footprint editor?
> Even if they w
This bug[1] has reared it's ugly head again so I am going to fix it once
and for all before the stable 5 release. We cannot continue storing
objects on deleted layers in the board file which cause the DRC to pass
connection tests when in reality there are failures. I don't really
have the time so
Le 26/09/2017 à 18:20, jp charras a écrit :
> Le 26/09/2017 à 13:47, Wayne Stambaugh a écrit :
>> Oliver,
>>
>> Thanks for making the changes.
>>
>> JP,
>>
>> Would you please take a look at this patch set when you get a chance.
>> You are more familiar with the board zone code than I am so you may
Hi,
it seems the RAID controller in my server has died completely now, and
replacing it and keeping the rest of the system intact isn't an option
(the new controller has a different connector for the disks, which means
a different backplane, which is not available for the case I have, so I
need to
What's the rationale to limiting this to copper layers only?
Why not have it available for all layers?
It's probably unlikely but if a silkscreen pour is made and a keep out is
required, as I understand it, it would make sense not to limit features
necessarily to select layers.
--
Andrey Kuznetso
I was thinking about documentation layers used to illustrate areas for
conformal coatings... keepouts around connectors and sensors might help to make
things clear.
Regards,
Clemens
On 2017-09-27 19:22, Andrey Kuznetsov wrote:
> What's the rationale to limiting this to copper layers only?
> Wh
I am sure that responding to this message awards me the Golden Shovel
for digging out the oldest thread ever, but I think the patch indeed
makes the interface look better.
I changed it a bit to avoid code duplication and managed to test it on
our supported problems without any issues.
On behalf o
Thanks JP!
On Thu, Sep 28, 2017 at 3:10 AM, jp charras wrote:
> Le 26/09/2017 à 18:20, jp charras a écrit :
> > Le 26/09/2017 à 13:47, Wayne Stambaugh a écrit :
> >> Oliver,
> >>
> >> Thanks for making the changes.
> >>
> >> JP,
> >>
> >> Would you please take a look at this patch set when you g
On 2017-09-26 13:38, jp charras wrote:
> The Gerber file is broken:
> the line:
> %FSDAX33Y33*%
>
> is incorrect
Thank you!
Since I cannot do anything about this proprietary non compliant EDA tool, would
it be possible to support these wrong but obvious lines anyway (maybe after
showing a war
Hurray for shovels! And as a fan, thanks Windsor!
On 28/09/17 10:38, Maciej Sumiński wrote:
I am sure that responding to this message awards me the Golden Shovel
for digging out the oldest thread ever, but I think the patch indeed
makes the interface look better.
I changed it a bit to avoid cod
Hi Wayne,
I'll back you on this decision.
It's more than once cost both time and money, to say nothing of
frustration to multiple users.
Personally, I've not been caught with sending a board to production in
this state, but I certainly have run into the problem and caught it
during routing (
Hi Jon-
Thanks for catching that. The delete node/delete connection follow a
different path to deletion, so I missed them initially. As I was doing
this, I noticed a couple of corner cases where junctions were not properly
added/deleted, so this fixes that issue as well.
There is one remaining
Hi All
I have to agree with some of the other posters, why not use git as it
was intended?
Specifically I think the following makes sense.
- Keep the multiple repositories, this helps when a company only wants
to make certain sets of libs available to it's staff
- Have a master reposit
+1 on this approach, to me this is the obvious way that it should be
done. However, my opinion is not important, I'm not a contributor. :)
On 9/27/2017 8:37 PM, David Godfrey wrote:
Hi All
I have to agree with some of the other posters, why not use git as it
was intended?
Specifically I thi
+1 also
It allows a company to start with the libraries at some point and keep
them consistent (by forking) and they can easily cherry pick changes or
do wholesale merges with their changed libraries, as they desire. And
for a casual user who just uses things, "as is" it will just work.
On 2
16 matches
Mail list logo