Eeschema keeps loading wrong symbol

OK, another weird issue here. I’m trying to place a 74HCT245 in my project. Unfortunately, the power pin keeps renaming the attached net to VCC when I want it to be 5V. Simple enough, copy the symbol into my own library and unhide the power pin.

Imgur album below shows the progression of events:

  • First, there’s the original symbol in the default libraries.
  • Second, I’ve unhidden the power pin and done a quick, cosmetic alteration to it.
  • Third, I’m putting the modified symbol into my schematic - note that the modified pin is visible in the preview.
  • Fourth, the old symbol, with the hidden pin is what is pasted into my schematic. When I open that symbol in the editor, it opens the copy in the read-only default library. WTF?

Anyone have any insight into what is going on here? I’ve even closed and restarted the application to make sure that it’s not some weirdness with the whole symbol copy operation.

edit - I just looked at the respective library files and it does look like the edited pin is in my library copy of the symbol. Any ideas as to why Eeschema would ignore my symbol add from my library and substitute the one from the default library instead?

You encountered one quirk of the soon-to-be-replaced™ component library framework.

note the note there:

PS: yes, we’ve all been there & got the T-shirt to prove it :wink:

Ah thanks, that’s the cause. I know what happened. my personal library used to be top of the load list but got dropped yesterday for some reason. When I re-added it, I forgot to push it to the top of the list. Any ETA on that new Eeschema release yet? I am anxious to have Eeschema work more like PCBNew.

You gotta ask that @c4757p , @cbernardo or @jsreynaud I guess

Why not modify the name when you change the symbol
…_dh
then no duplication

Why should I? The part is a 74HCT245, that’s what I want to call it. It’s annoying enough that Kicad’s default library parts use hidden power pins, forcing me to have to make cluttering and useless nearly-identical copies of parts in my personal library. I’m not going to further obfuscate things by having to tack on some arbitrary pre or post-fix modifier to the name.

1 Like

Until the new schematic .sweet library structure is released we are stuck with it.
Meanwhile whoever it was who thought hidden power pins was a good idea gets cursed every day by frustrated KiCad users all over the World

1 Like

I have no problem with the hidden power pins in general - they serve a purpose. But making that the default behavior in the standard library was a poor decision at best. Thankfully, KiCad does have a workaround.

If there weren’t a new Eeschema on the horizon, I’d be more amenable to doing what you suggested but I’m content to wait this one out.

To be honest, I’ve been quite happy with the overall direction Kicad has been moving. I tried using it a few years back and hated it. Even when I picked it up again about 6 months ago, the Debian default install was still terrible. But when I tried the PPA version, there was a dramatic improvement in the overall quality. I’m hoping that the trend continues. Right now, I’d rate Kicad about equal to Eagle in frustration level. If Eeschema can get modernized and the different UIs for the default/OpenGL and Cairo can get standardized, it’ll be a very nice program.

The hidden power pin idea made sense for TTL, but became a liability when the 74HC00 series was released, at least before 1988 and long before KiCad started

My understanding is that new schematic library management will not be in next major release (v5), according to what Wayne has said on the developer mailing list.

What purpose might that be?

1 Like

Power symbols. (Even there it might be better to have a separate electrical type that tells the system “this is a power symbol pin”.)

I’m specifically referring to the “hidden” part.

It’s a hack: hidden power input pins are interpreted as global labels. (That’s why power symbols have a hidden power input pin of length 0)
In other words: if a pin is hidden AND power input -> it is a global label with the label name equal to the pin name.

Yes, I understand what they are and how they work, but what useful purpose do they serve when they are the power pins of IC packages? They seem to cause more problems than they were intended to fix.

I agree there could be a far better way to do power symbols without having to embed a hidden pin.

1 Like

I think there are two separate reasons given :

1 - Reduce visual clutter on the schematic
2 - Provide “auto connect” feature to save users the bother

(1) Can also be achieved with a separate power block ( which would be my preference)
(2) is a “nice to have” but not really a huge advantage IMO

Clearly if a pin is hidden, then it should be either NC or an auto-connect of some sort, because obviously the user can’t see it to connect it (in normal use, I know “hidden” pins can be made visible).

So making the pin hidden for case (1) leads to (2). “Auto-connect” could still work without hidden pins, the sensible thing would be to add a flag to the pin attributes rather than rely on a magic combination.

Personally I would ban hidden pins, but I’m not in charge :slight_smile:

Hidden power pins that auto-connect are one of those features that are only ever argued in favor of by hobbyists. Engineers, who have much more experience and have seen the sorts of problems various anti-patterns can cause, know better.

And yeah, new eeschema is still a long way off unfortunately. It’s a ton of work.

1 Like

This begs the question of why they are used in the KiCad library then?

This is the puzzle, boards stuffed full of 5V only 74LS00 series logic were already obsolete 20 years ago

They are only used in the 74xx library which is awaiting a big overhaul.
(Nobody had the time/willpower to do it. Who wants to volunteer?)
Also i think the klc discourages the use of hidden power pins.

See:

Or the latest reincarnation: