kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Tue, Sep 09, 2014 at 03:42:18PM +0100, Brian Sidebotham wrote:
> I understand what you're saying about there currently being nothing of
> the reference on the assembly layer. However, essentially bodging
> something on now just creates an obstacle for someone later on down
> the line who wants to implement this more thoroughly.

Well it was a four liner making the assembly plot actually useful.
Seemed a good stopgap for the current situation (and really not a big
ostacle to whatever:P); I just backed it off, anyway. If someone is
interested however is in the history.

> If I don't see it on screen, I don't want it suddenly appearing in a
> plot silently. If you want IPC compatible modules, then I guess you
> need to add the reference designator text to the module at the
> insertion point.

The problem is, now plotting the assembly shows... no refdefs. Showing
the refdef as in the silk would be better but simply just another
special case (which, quite correctly, you want to avoid).

> Obvious I don't think is generally good. Just making another
> special-case item is like replaying the old broken record. There's
> nothing really special about some text on a layer, and just because
> it's a reference designator shouldn't mean it's special either.

Well, the reference designator *is* special, since IIRC that's the only
way to know what component is that (i.e. the text string is also the
main identifier for the module). Not having reference or value would
create quite a big update anomaly when processing the netlist; the value
is not so important as the reference, but it comes from the netlist too.
It's just there, not particularly important (except for the change
module feature) but still a special field.

> I don't think we want yet another tickbox, or another "special" item
> to worry about - it's just dynamic text.

I'd say it's simply a 'user' text in the module; only it can live on
other layers than silk, in general. The dynamic thing could be easily
done in the display/plot routine.

> Variable substitution in text on any layer would be my preferred way
> of achieving this.

OK, then the plan is to add some interpolator to the 'user' text.

> 1) Text on any layer in the module editor (with perhaps the exception
> of copper layers if this introduces issues with DRC)

That was 'the usual limitation' I was talking about. UI work on the
module editor shouldn't be difficult; there is already the graphic
entity property dialog as a reference on how to handle the layer picker.

> 2) Variable substitution so that the value and/or reference designator
> could be included on any other layer including an assembly layer.

Yes that would be the following step. After having "Foo" on the assembly
layer, "Foo %R" or such would need to work. Probably wx already has some
pattern replacement facilities to do that.

> That sounds like a good way forward. The library team will have a job
> in front of them adding in assembly features, but at least they'll be
> able to decide what happens on a per-library basis.

It's just a text field; when you draw (or generate) the fab outline just
place it in the right place (which would be probably the same for the
default silk refdes).

> This is the most open solution I think, but maybe few more ideas
> bounced around may provide something better still.
> 
> All just my opinion, but I'd be willing to add the work to my list if
> you don't have the time and we agree on a more thorough route for
> handling this type of entity. I think we already agree actually!

The ideas are reasonable. I'll start checking around to see if layers
different from silk are properly handled (with a *lot* of luck:D); in
the meantime if you want you could do the UI modifications (mostly the
module editor and showing the text in the 'right' color: the one from
the visibles for refdef or value and the layer on for other texts. Also
the color for the "Text Front" and "Text Back" visibles are to be
removed (since they are not used anymore). At least I can't see a use
for them.

-- 
Lorenzo Marcantonio
Logos Srl