Eeschema not correctly building netlist 6 pin optocoupler

Schematic Simulation (Ngspice)
1

KiCAD V9.04, symbol used CNY17-1 and 4N35

This is similar to prior forum post.

I’ve now replicated it with both 4N35 and CNY17-1 optocouplers. I discovered the problem trying to use ngspice (via KiCAD)

KiCAD example files are zipped and attached.

THIS IS AN EXAMPLE THAT DEMONSTRATES THE PROBLM. E.g. yes I know that U2 seems to have Anode & Cathode reverse biased!

Resulting Netlist is:

![4N33_Test|497x277](upload://n86Myv5501fyr9UF0AT50NJLuYy.jpeg)
.title KiCad schematic
.include "C:/xxxxxxxx_Rextor Group/KiCAD_ngspice/CNY17_10ma/Spice Model_BJT_10mA/CNY17_10mA.lib"
V1 VCC GND DC 5 
R4 VCC Net-_R4-Pad2_ 330
XU2 GND Net-_R4-Pad2_ unconnected-_U2-NC-Pad3_ GND BJT_10mA
R1 VCC Net-_R1-Pad2_ 330
XU1 Net-_R1-Pad2_ GND unconnected-_U1-NC-Pad3_ GND BJT_10mA
TP2 __TP2
TP1 __TP1
R2 Net-_R2-Pad1_ VCC 2k
R3 VCC Net-_R3-Pad2_ 2k
.end

NOTE the “unconnected-U1-NC-Pad3” that’s the NC that is built into both the 4N35 and CNY17-1 schematic symbol.

4N35 schematic symbol:
4N35_symbol

The spice model is from Vishay, it’s the model used for many optocouplers.

* Library of DC Input Phototransistor Output Optocoupler BJT_10mA
* Copyright VISHAY, Inc. 2018 All Rights Reserved.
*
* ==== BJT_10mA ====
* A = diode anode
* K = diode cathode
* C = BJT collector
* E = BJT emitter
*$
.SUBCKT BJT_10mA A K C E PARAMS: REL_CTR=1
D1 A D DIRED	;IRED
Vsense D K 0 ;IF Current sense
Hd R 0 Vsense 1	;I-V
Rd R T 10K
Cd T 0 0.2n
Rdummy B 0 4G
Q1 C B E [E] QBJT ;phototransistor
* V-I
Gpcg C B TABLE  ;Photodetector {(IC vs IF) / Q1 BF}
+ {0.34*REL_CTR*(V(T)**1.658*exp(limit(4.3-60*V(T),-50,50))*
+ ((4*10**(-9)*(REL_CTR**6))-(7*10**(-7)*(REL_CTR**5))+(5*10**(-5)*(REL_CTR**4))-(0.0015*(REL_CTR**3))+
+ (0.023*(REL_CTR**2))-(0.155*(REL_CTR))+2.2261)/100)}
+ (0,0) (10,10)
.model DIRED D IS=1P N=1.948621 BV=6 IBV=10U
+ CJO=18.8P EG=1.424 TT=500N
.model QBJT NPN IS=3.64P BF=100 NF=1.193293 BR=10 TF=13N TR=350n
+ CJE=5.16P CJC=18P VAF=65 ISS=0 CJS=7.74p
.ends
*$
**==================================================================*
* Note:
* Although models can be a useful tool in evaluating device performance,
* they cannot model exact device performance under all conditions, nor
* are they intended to replace breadboarding for final verification.
* Models provided by VISHAY Semiconductors GmbH (“Vishay”) do not represent
* all of the specifications and operating characteristics of the product to
* which the model relates. The models attempt to describe the characteristics
* of typical products. The current data sheet information for a given
* product represents the final design guideline and includes actual
* performance specifications. The accuracy, reliability and compatibility
* of models provided by Vishay are not guaranteed or warranted in any way
* and Vishay disclaims liability of any kind whatsoever, including, without
* limitation, liability for quality, performance, merchantability and fitness
* for a particular purpose arising out of the use, or inability to use a model.
* Vishay reserves the right to change models without prior notice.
* The products described herein, including the model and any results produced
* using the model, are subject to the specific disclaimers set forth at www.vishay.com/doc?91000.
**===================================================================

4N33_eeschema_test.zip (10.9 KB)

2

I want to make sure everyone knows this IS NOT an ngspice problem. It is an Eeschema problem.

The netlist I included was generated by exporting the netlist using directly from the schema view. It is not the ngspice imported listing… but since Eeschema incorrectly built the netlist - ngspice would also see an improper netlist.

3

Please edit the model. Don’t use ‘Blockquote’, but ‘Preformatted text’.

4

Have you set the schematic pin number to model pin number map in the symbol properties?
The model order is SUBCKT BJT_10mA A K C E. Which is not the order of the symbol pins.

5

Edit which model? I’d tried editing the symbol - removing the “NC” on in the symbol library and creating a new symbol. Same problem. The Vishay spice model is the one used by other spice and CAD tools.

Pin 3, on the symbols is marked “NC” internally. exposing the pin and marking it as “NC” on the schematic makes no difference. I went as far as changing the symbol so the anodes are labled A,K with the symbol lines identified as “open collector and open emitter” issue remains.

Sorry about the blockquote – it was after a long day and late at night.

6

I used the common optocoupler library parts included with KiCAD the 4N35 and CNY17-1. The board autoroutes correctly, the PCB loads the correct list for the rats-nest. But the exporting of the netlists for spice is incorrect.

We really don’t want to break other parts - to work around what looks like a bug in the Eeschema netlist export process.

If the problem was only that the pins of the collector and emitter were reversed - I’d edit the spice model to fix that… but the problem is Eeschema incorrectly creates a netlist using the internally “unconnected” pin 3 and frequently skips the emitter.

7

It still sounds like you need to edit the pin mapping in the simulation model properties of the symbol. That’s how you adjust the mapping of pins in the KiCad symbol to the spice model. Obviously all the different pinouts in the world can’t map to one model file.

It’s described in the manual here:

If you have done this and it still doesn’t work, take a screenshot of your current assignment table.

8

In addition to the necessary pin mapping, there is a incompatibility of the Vishay model with ngspice. Attached you will find a working solution.
BJT_10mA.lib (2.2 KB)
I will check how to make ngspice compatible to the original model.

Edit: Another Update of the model.

9

Thanks, I’d looked at remapping pins, but one of the points is that even with the symbol foot print marking pin three as “NC” internally, the netlist built ignored that and still mapped pins sequentially.

My point is that the netlist build should skip over pins that that have the internal pins marked as “NC”. It should have skipped on to the next pin 4, which would have resulted in the mapping of pin 4 to the collector and pin 5 to the emitter.

Both of those are piece of cake to fix in the remapping of pins.

Since this question has popped up once before, I’ll post the screen shots so future users that query looking for corrections can easily spot the pin map.

But again, this is like mapping a tab for a TO-220 part as one of the electrical pins, even though the tab might have been isolated internally and is only there for a thermal connection. If marked internally as NC, it should be skipped when the initial pin mapping for spice simulations are done.

10

You can open a feature request for skipping NC pins in the initial mapping if you like. May be a handy QoL thing when you have a part with NC pins.

But you do still need to pay attention to the mapping because even if you skip the NC pin the symbol pin order is AKEC(B), but the model is AKCE.

11

Agreed, but the reversed C & E (D & S) is really easy to spot once the simulation run starts. It becomes really obvious. Much like reversed diodes…

I will document - the mapping process - so others can spot it quickly if they retrieve this entry while searching “not connected”.

PS, I’ve a different problem I’m also fight, remapping pins on TLC556 (dual timer) only seems to stick for one side at a time… growl - more digging.