On 9 September 2014 04:56, Lorenzo Marcantonio <l.marcanto...@logossrl.com> wrote: > On Mon, Sep 08, 2014 at 10:27:45PM +0100, Brian Sidebotham wrote: >> Sorry, but I don't like this patch because I want control of where the >> reference text goes on both assembly and silk layers. It doesn't >> necessary want to go in the centre of an electrolytic cap for example. >> Only for the very basic components is the centre an okay choice. >> >> I would rather just allow to have a reference object on the assembly >> layer as well as the silk layer. > > I implemented the IPC rule which tell that's the reference on assembly > goes to the insertion point (for pick and place cross-check). I think > it's OK if someone doesn't like it :D In fact it's silly for THT > component were the insertion point often is on pin 1. > > However at the moment the reference simply *doesn't* appear on assembly > so it doesn't actually breaks the plot IMHO; at least at the moment is > useful.
Hi Lorenzo, Sorry for the late reply. 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. I think as with the silk screen version of the reference, we should add the same to the assembly layer. However, I'd much rather see us use text substitution for things like this. I realise that's a more involved task - but it's even more involved if first we have to try and support old behaviour that's essentially been hard-coded into the plotter. 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. > I agree with you that a separate designator would be useful. The whole > story is here > http://blogs.mentor.com/tom-hausherr/blog/tag/reference-designator/ > In short, silk refdes must be always outside the part, assembly refdes > needs to be always inside the part; quite a conflicting requirement... > since on silk you need to always hand place it (if it fits on the board, > i.e. never in my case:D) and many CAD have no separate assembly origin > it get placed on the insertion point (if you can't move it as you > reasonably asked). > The big problem is that reference and value are two slots in the module > class, not entities in the module and are treated in a special way (in > eeschema instead they are simply the 'first' in the attribute list). And > that text (other than in the file format) isn't really handled in layers > other than silk (could work but probably something would glitch). In > fact, if you noticed it, they are not even controlled by layer but from > the 'visibles' palette (and have their own colors). > > How to handle that? The obvious thing would to have a separate AssemblyRef > member. And duplicate the whole shebang for handling the current > reference field *all over* pcbnew, adding a keyword in the file format > and so on. Well, it smells to me:P what if you also want value on > assembly? :D 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. > Also how to handle it in the UI? do we allocate another visible index? > Even the picking code would need to be duplicated... I don't think we want yet another tickbox, or another "special" item to worry about - it's just dynamic text. > Suggestion on how to handle it are well accepted. I was thinking maybe > in some kind of printf-like expansion in user text where you could place > %R or %V or something and put it on whatever layer you wanted to achieve > the effect. The %-thing would be easy, checking that text works on > different layers is not :D for assembly we could just put a rule that > use a default if no other text is specified on the layer... Variable substitution in text on any layer would be my preferred way of achieving this. > So a first step (useful in any case) would be changing text-in-module entity > specifications from: > > - Reference lives on SilkTop (and it's controlled by a own 'visible') > - Value lives on SilkTop (and it's controlled by it's own 'visible') > - User text lives on SilkTop (and it's controlled by the master 'show > text' visible) > > ...to: > > - Reference and Value *no change* (seems fine to me) > - User text on any layer allowed in the module (i.e. the usual > restrictions which change from one day to another); I think it could > be controlled by the same master visible but taking the layer color. > > That would be useful for having comment text in the module (I've missed > the feature in the past, actually...). Probably the new module editor > can handle the layer change, I didn't check. Otherwise I think that > simply adding the usual layer chooser would do the trick. > > In the meantime I have no problem in backing out (maybe partially, only > the 'pull to origin' piece) the patch. Maybe Yet Another Option on the > plot dialog for enabling the movement? An assembly plot with the refdes > placed like on silk would be better than without refdes at all. > > Tell me how do you like it Yes, two things we really need - 1) Text on any layer in the module editor (with perhaps the exception of copper layers if this introduces issues with DRC) 2) Variable substitution so that the value and/or reference designator could be included on any other layer including an assembly layer. 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. 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! Best Regards, Brian. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
