Issue with led-3.sym

Hi,

From the top of my mind:

"pinseq" is a mandatory attribute (http://wiki.geda-project.org/geda:master_attributes_list#pinseq).

pcb uses the "pinnumber" attribute (http://wiki.geda-project.org/geda:master_attributes_list#pinnumber).

Kind regards,

Bert Timmerman.

That would then imply that changing the pinseq attribute so that the symbol works properly with ngspice through gnetlist would not adversely affect anything in pcb which does not use this particular attribute. Should I then make a bug report suggesting this change to the led-3.sym (and by extension the diode-3.sym) attributes for compatibility with both ngspice and pcb?

Michael Milliman wrote:
> Question #676070 on gEDA changed:
> https://answers.launchpad.net/geda/+question/676070
>
> Status: Answered => Open
>
> Michael Milliman is still having a problem:
> That would then imply that changing the pinseq attribute so that the
> symbol works properly with ngspice through gnetlist would not adversely
> affect anything in pcb which does not use this particular attribute.
> Should I then make a bug report suggesting this change to the led-3.sym
> (and by extension the diode-3.sym) attributes for compatibility with
> both ngspice and pcb?
>
>
Hi Michael,

Please check against the other diode symbols.

IIRC this symbol was introduced to solve the mess with the other 2 diode
symbols.

Kind regards,

Bert Timmerman.

> Comments indicate that this may be intentional for compatibility with some manufacturers which specify pin 1 as the anode of their product.

Pin assignment on three-pin components is generally a hassle. You should check all pin numbers manually, and create a custom symbol if necessary.

> The question is, will this change of pinseq attributes cause any additional issues with pcb for example? I noted that in the comments on the reported bug, that changing the pin numbers directly did have potential of causing issues with pcb.

The documentation on this may be a bit confusing.

For regular components which don't make use of the slotting mechanism, the pinnumber= attribute defines the pin number. For slotted symbols, the pinseq= attribute defines the “raw”, unslotted number, and the actual pin number is derived from this, the slot number, and the slot definition.

In contrast to other backends, the simulation backends use the pinseq= attribute as the pin number. This is kind of a hack: it allows splitting a component into multiple parts for simulation, but it also means that the pinseq= attribute has two separate, unrelated meanings: pin number for simulation, and “raw” pin number for slotted components for anything but simulation.

So, if the part in question isn't slotted, changing the pinseq= attribute won't have any effect on layout. If the part *is* slotted, you'll have to change its slot definitions accordingly.

Yes, according to my research, the diode-3.sym was introduced to solve the problem where some manufacturers specify pin1 as anode and others as cathode. It appears that the led-3.sym symbol was introduced for the same reason. AFAICT, when the change of pinnumber was made, the pinseq attribute was also changed, creating issues with the simulation backends. From this conversation thread, as this component is not a slotted component, making the pin 1 pinseq attribute equal to 2 and pin 2's to 1 will have no adverse effect with the layout backends, and does solve the problem with the simulation backends. This change should be made to both the diode-3.sym and led-3.sym symbols. AFAICT these are the only two symbols affected. IMO, this being the case, a bug should be filed against these two symbols to affect this change.