On Tue, Feb 16, 2016 at 12:40:34AM -0700, Andy Peters wrote:
> I understand, I was just trying to figure out why they rejected the
> files. After some back and forth e-mail, I think it’s because they’re
> using an ancient version of Cam350 that doesn’t understand Gerber
> Extended Attributes. (I
Le 16/02/2016 09:08, Mikael Arguedas a écrit :
> Hi,
>
>
>
>
> On Mon, Feb 15, 2016 at 11:49 PM, jp charras wrote:
>
>> Le 16/02/2016 07:44, Mikael Arguedas a écrit :
>>> Hi Miguel,
>>>
>>> Thanks for the clarification. I can now appreciate the difference. In
>> this
That is a very good point. Will do.
Thanks for the feedback!
On Feb 16, 2016 12:26 AM, "jp charras" wrote:
> Le 16/02/2016 09:08, Mikael Arguedas a écrit :
> > Hi,
> >
> >
> >
> >
> > On Mon, Feb 15, 2016 at 11:49 PM, jp charras
> wrote:
> >
> >>
Hi Bernhard,
I have just pushed your patch (rev 6560). It is better to avoid #ifdefs
if possible, but I am not able to provide a better solution at the
moment and your changes have a positive impact on the overall
performance. Thank you for taking care of the problem.
Regards,
Orson
On
Hello,
A couple of notes...
- The KiCad Spanish translation was featured on hackaday.com (first
message ever in Spanish on hackaday). Maybe it is of interest to publish
it on the KiCad webpage in the (DISCOVER->IN THE MEDIA) section.
Link:
Hello!
On 2016-02-16 09:30, Mikael Arguedas wrote:
> If you are implementing the ceiling function in a parent class, use 0.05
> mm, because it will be not necessary used for sizes, but also for
> distances, and round the half size if needed.
Ok, I might be nitpicking again:
Can we
Le 16/02/2016 13:33, Clemens Koller a écrit :
> Hi, Jean-Pierre
>
> On 2016-02-16 13:04, jp charras wrote:
>> Le 16/02/2016 11:59, Clemens Koller a écrit :
>>> On 2016-02-16 09:30, Mikael Arguedas wrote:
If you are implementing the ceiling function in a parent class, use
0.05
> On Feb 16, 2016, at 1:02 AM, Lorenzo Marcantonio
> wrote:
>
> On Tue, Feb 16, 2016 at 12:40:34AM -0700, Andy Peters wrote:
>
>> I understand, I was just trying to figure out why they rejected the
>> files. After some back and forth e-mail, I think it’s because
Today, the smallest SMD chip is the 01005 which is 0.010”x0.005”, which in
metric units is about 0.25mmx0.125mm(0.13mm). using a grid of 0.05mm will drive
the courtyard to be odd shaped in relation to the part. I would suggest to be
able to lower the grid resolution to 0.01mm to deal with these
Le 16/02/2016 17:55, Andy Peters a écrit :
>
>> On Feb 16, 2016, at 1:02 AM, Lorenzo Marcantonio
>> wrote:
>>
>> On Tue, Feb 16, 2016 at 12:40:34AM -0700, Andy Peters wrote:
>>
>>> I understand, I was just trying to figure out why they rejected
>>> the files. After
I agree with that, most of my small components dont comply with this KLC
rule and I live very well with it.
I split this patch in two. Here is the part which takes care of setting the
attributes. I'll submit the rounding function patch later today.
Cheers,
Mikael
On Tue, Feb 16, 2016 at 10:00
Hi guys,
Here is the rounding function patch
Cheers,
Mikael
On Tue, Feb 16, 2016 at 10:05 AM, Mikael Arguedas wrote:
> I agree with that, most of my small components dont comply with this KLC
> rule and I live very well with it.
>
> I split this patch in two. Here
These enums are silently treated as equivalent in the ERC, because the
values are casted to integers. This works for the most part, because the
values are similar, but this is in no way enforced, and there is a small
inconsistency (NET_UNSPECIFIED vs PIN_PASSIVE).
This turns the storage into a
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eeschema/dialogs/dialog_lib_edit_pin_table.cpp b/eeschema/dialogs/dialog_lib_edit_pin_table.cpp
index f905a55..5a6202e 100644
---
have the environment variables
${KIPRJMOD}
${KISYS3DMOD}
been dropped by the new 3D refactoring?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
Hi Maurice,
Cirilo will be the best person to reply.
I know that the KISYS3DMOD is working for me...
I dont know about KIPRJMOD (on relation of 3d models plugins) but I guess there
is no change on that since the rest of the source code is the same as the
trunk. ( I checked and it is used by
Hi Maurice,
For legacy support ${KISYS3DMOD} is magically and invisibly supported by
the filename resolver. The resolver will also correctly resolve any path
specified like ${ENV_VAR}/some/path. However, once the new 3D plugin code
is merged I would discourage any future use of ${KISYS3DMOD}
Yes the latest submitted patch expose an optional parameter (threshold) to
allow to chose the grid size you want to round on, if not provided 0.05mm
will be used as a default.
This now uses the python built-in "round" function for more readability and
avaid reimplementing functions provided by the
Hi Cirilo and Mario,
thank you for your reply ...
I'm testing the new 3D refactoring, built from this repo
https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
in windows 8/64b
what I'm experiencing is that I cannot display any 3D model at all...
I tried also with an absolute path, and
Hi Maurice, thanks for trying it !
Cirilo can give more details, but because of the 3D plugins, you have to
build.. and install it.
I am testing in on Windows once in a while, building it on a MSYS2
I run 'make install -j4'
and run kicad
I got help on IRC from nickoe (thanks!) on setup and
Nice!
"now I can test the models in the new 3D environment :)"
In relation to the openGL render mode, you should expect similar results. There
are still things missing and some tweaks need, but visually it should be
similar.
(supposing you choose in current kicad to use model materials and
On Tue, Feb 16, 2016 at 09:55:48AM -0700, Andy Peters wrote:
> Let’s be honest. They’re using cracked versions of Cam350.
A board fabricator *can* afford at least Cam350. The good ones use genesys2000
:D
Also, if you have the cracked version *at least* use the latest cracked
version, the
22 matches
Mail list logo