Multiunit symbol reference/value placement same for all units

Currently, all multiunit units have their reference and value fields in the same place. This in and of itself makes symbols non-compliant to KLC S3.8.
Any plans to change that (although maybe not in 6.0.0-rc1)?

The KLC might need reworking here. In reality the rule is just there to have some consistency during review. In the schematic the fields are autoplaced anyway so users will not really notice where in the lib the fields are. I have not played with nightlies in a long time (one of the reasons for my resignation) so i have no idea what the new file format is capable of.

v6 text fields are per symbol, not per unit, same as before.

How does that contradict S3.8? What am I missing?

Screen Shot 08-29-20 at 09.16 AM

You cannot have the reference/value fields above the symbols and at right side in the power symbol at the same time.

That’s why currently the symbols look like this:

If the units do not all have the same size (like is typical with a micro controller for example or even with logic symbols having extra units for the power symbols) then it is near impossible to place the text fields outside the symbol body and still have them fitting all units.

However S3.8 does not say anything about field placement. The screenshot there is taken from eeschema after the auto placement algorithm placed the fields.

To be honest i don’t think we even have a written rule about where the fields must be placed (just an unwritten one that we follow) I thought we have but well seems we lost it or i can’t find it.

@straubm the text is what counts in the rules. If the text does not say something about fields they are not part of a rule.

Oh, it’s about the example image. Got it.

Many of those are kind of obsolete. You’re welcome to keep notes as you stumble across them.

We also tend to use “floating” power pins on multi-unit logic, opamps and such so they can be placed on one of the units or used standalone. See the current LM2901 symbol for example.

Basically, it’s not nit-picking with that S3.8 stuff, be it as it is.
It simply is inconvenient that you have to move and left adjust the fields after adding them to the schematic as they are now. And even if so, it would be less tiresome to have the fields in the main symbols in the right place and to have to adjust the power symbol only. Which are by far to wide IMHO.
But maybe I miss something, or I’m really nit-picky or I didn’t have my first coffe or… :slight_smile:

That’s what I do right now, hence the post.

I had coffee before replying and still didn’t get, so I don’t think that’s the problem :wink:

So what we discovered is that the symbols are in compliance with the current KLC and that the library team really is of the hook here.

Next step make a feature request to tell the devs about this missing feature of the new file format.
I kind of expect that the inheritance stuff could possibly be able to do what you want but am unsure how much of that will be implemented as i did not follow along with the file format discussions after some point.

Another option would be to have the autoplacement algorithm turned on :wink: After all it should already place the fields like they are in the screenshot you post (As i made the screenshot by just placing the 5 units in eeschema without any extra steps after that)

My Gosh, I missed that autoplacement checkbox all the years (or at least since it’s there). That’s really embarrassing…
Anyways, age 67 I’m still open to learning all the time :wink:
Sorry for eating up your time.

I believe the new format allows for that as units are basically symbols nested inside symbols in v6, the problem seems to be the missing UI in Libedit and Eeschema possibly couldn’t deal with it yet.

I can make manual changes to a multi-unit symbol later (for testing).

1 Like

But then, I still think the power symbols e.g. in the 74xx library (that’s what I’m sifting through right now) are far too bulky. I think the “floating” approach is much better.
Should that be changed in the libraries (disregarding manpower aspects)?
And then: where can that be discussed (unlessy I simply should shut up :grinning:). is not the right place for such details IMHO. Is there a mailing list for the symbol/footprint team? Or is it the devs mail ist?

Ideally, search for open issues on Github, comment on them with your findings or open new ones.

1 Like

The logic symbols are scripted by @bobc There was a lot of discussion back when the symbols were made and the feedback was about 50/50 regarding “with or without rectangle” for the power unit. So bob just made them with rectangle which is totally fine.

Turns out the current implementation can’t deal with overridden properties although the format spec ( seems to allow it (@stambaughw?).

I don’t think this is very pressing and I assume I’ll have to pester the devs with more important last minute changes, so v6 probably isn’t going to support per-unit reference/value placement.

The full inheritance model has not been implemented. Only simple inheritance from a single parent symbol has been implemented. This document is a development document and should not be used as the released file format. There are many things in this document that wont get implemented until V7 or later. I strip out all of the features that are not implement from this document to create the file format document for the V6 release which will be the official document.

1 Like

So it’s reasonable to assume that 5.99 is basically feature complete as it is now, symbol format-wise?

I do not do much these days with TTL, had not realized the power part was that big.

Just for fun, I did a quick 'n dirty experiment and designed 2 new variants myself.
For reference I also placed the current power symbol of an opamp on the left side, and current TTL power S. on the right.

The LS01 variant is narrower, but then the component text is wider than the symbol, so this does not help if you have a lot of them on a sheet.

I do not like the “auto placement” much myself.
Best would be if the texts can have separate locations for different units, but that’s probably not in the file format.
Next best thing is to place them in a reasonable location for the most units of a symbol. So for the 4 NAND gates instead of the power unit.

After looking at it for a while…
It seems that 150mil pin length would be better, the pin numbers are a bit too close to the body. I have a vague memory that the KLC has a rule for this.

Both these experiments look better to me than what’s in the libraries, but I’m biased as the “designer”.
Logic_Power.dcm (706 Bytes) Logic_Power.lib (5.5 KB)

Updated screenshot to include standard and small R & C for size comparison

When TTL was popular, it used to be very common to have a separate sheet just for power blocks, showing associated decoupling capacitors, so size was rarely an issue