kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 04/06/2014 18:07, Tomasz Wlostowski a écrit :
> On 04.06.2014 17:31, jp charras wrote:
>> Le 04/06/2014 12:13, Tomasz Wlostowski a écrit :
> 
>>> What would be the issue to add them to the sexpr file formats, that are
>>> meant to be extensible?
>>
>> First of all, my response was related to the current work on footprint
>> libraries refactor.
> 
> Hi Jean-Pierre,
> 
> What is the status of this work? Is there any plan/blueprint publicly
> available?

The team which works on libraries has its own mailing list:

kicad-lib-committers@xxxxxxxxxxxxxxxxxxx


>>
>> It is not related to the CERN work package 4, which is an other thing.
>>
>> I agree the number of layers (both copper layers and non copper layers)
>> must be increased.
>>
>> With the current layers, one cannot add a courtyard info (a new layer +
>> courtyard data) without breaking the compatibility with current Pcbnew
>> version (including stable version).
> 
> We are very happy to hear that compatibility with stable Kicad versions
> is gaining importance.

It was always the case.
But new items always break the backward compatibility.

Just we tray to avoid to break this backward compatibility when it is
not mandatory.

> 
> How about modifying the PCB parser to produce warnings for designs that
> contain layers unsupported by this particular version (same for new
> object types, such as arcs on copper layers, diff pairs, polygons in
> footprints, etc.)?

Never easy to manage unknown items.
the PCB parser currently generates a fatal error.

Perhaps it could be enhanced.

> 
>>
>> The main work is to add the code in modedit to add/edit polygons in
>> footprints (they are supported currently, because they are used to
>> create logos by bitmap2component, but there is no tool to edit them).
>> this is certainly 90% of the work.
> OK.
> 
>>
>> The DRC code to test courtyards intersection is very basic and is made
>> in zone management.
> We do have DRC improvements in our pipeline. I'm sorry to say that, but
> the current DRC is not acceptable for us: for example zone clearance is
> ensured by refilling zones every time the DRC is run. DRC is a check, it
> must not modify anything on the board. I would schedule courtyard
> checking after the new DRC engine is implemented.

Testing courtyard has nothing to do with zone refilling.

Testing courtyard needs only to calculate intersection between polygons,
which is easy with the code created for 3D view and zones management,
but it is not a zone refilling.

> 
> 
>>
>> Yes, good idea, I fully agree.
>> Note: for layers renaming, this is currently possible for copper layers.
>> for non copper layers this was possible, but due to many issues we had
>> due to this renaming, it was removed.
> 
> I meant just the display name, not anything that defines the structure
> of PCB/footprint files or the purpose of the layer.
> 
> BTW. I don't understand why layer sets are stored using layer names
> instead of IDs in the sexpr file format. Moreover, different footprints
> often use inconsistent naming schemes.
> 
> Looking at demos/video.kicad_pcb file, there are modules that use French
> layer names:
> (layers Cuivre Dessous.Pate Dessous.Masque)
> as well as the standard English ones or a mix of both:
> (layers *.Cu *.Mask Dessus.SilkS)

Layer names were some time ago translatable (depending on the version of
Pcbnew).
Therefore, mainly in docs (videos, tutorials...), you can find French
layer names, or Spanish names ...

Currently, copper layers names are editable by user, because when you
have boards with 8 to 16 layers (I made one 16 layer board, but most of
recent boards I made have 8 layers) you need to know the layer 3 if a
GND plane, the layer 6 is used to route analog signals, ...
and the best way is to give them a name.

This is not needed for dedicated technical layers, which have now fixed
names.

What is the interest to rename a solder mask layer?

> 
> Since layer IDs are constant, why use names (that can be modified by the
> user) to define the set of layers spanned by an item?
> 
> Is there any practical reason for that (other than serving a small
> fraction of users who wish to hand-edit the files)?

No, layer IDs are not constant (see CERN work package 4!):
when the kicad_pcb file format was designed, Wayne tried to avoid using
IDs in files, because:
- We know the layer number will increase, and therefore the layers IDs
will change.
- also because an human easily readable file format was expected.

The first draft of the file format was using IDs, and was abandoned (not
good)

- Using layer names also allows a sophisticated notation like *.Cu
*.Mask ..., which cannot be done with layers IDs

Using in a file format data which reflects the internal coding details
of an application is always bad: this is why binary formats are so stupid.

(Unfortunately, there are few place were internal coding appears, like
masks in allowed layers, but there are minor parameters)

> 
> Regards,
> Tom
> 


-- 
Jean-Pierre CHARRAS