kicad-developers team mailing list archive

["Patrick" <pmaupin@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, "Patrick" <pmaupin@...> wrote:
>
> 
> 
> --- In kicad-devel@xxxxxxxxxxxxxxx, "Patrick" <pmaupin@> wrote:
> >
> > 
> > 
> > --- In kicad-devel@xxxxxxxxxxxxxxx, "Lorenzo" <lomarcan@> wrote:
> > >
> > > --- In kicad-devel@xxxxxxxxxxxxxxx, kicad-devel@xxxxxxxxxxxxxxx wrote:
> > > 
> > > > File : /pompa.tar.gz 
> > > > Uploaded by : lomarcan77 <lomarcan@> 
> > > > Description : Test case for wrong netlist generation. Can also bepublished as an example for strictly non-commercial usage 
> > > 
> > > OK this is my test case. As an example is not to be took to seriouslyaltought it is of production quality:P it is meant to be a throw-away proof-of-concept board. The 'strange' component choice (and the mix of THT and SMD one) is because it's designed to be built with the component I have at hand in the workshop at work I.E. a >10A mosfet is NOT the usual choice driving a 3-4A load:D:D
> > > 
> > > Since it is a throwaway if you want you use it as a sample somewhere,just add attribution and a non-commercial notice. Oh well, you would have to write the firmware to make it work, anyway...
> > > 
> > > If someone is interested I could open source my symbols and module library (but they're optimized for the ISO font, I don't know how they look with the standard one).
> > > 
> > > A little trick I used: there are TWO ground references here (in industrial work even 3 or 4 are not so rare... just think about insulated interfaces). Since they are connected anyway i devised the funny symbol you can see in the upper left. The two nets can be then routed correctly and the symbol is a 'virtual' module with a 'graphic' line on the copper plane to givethe connection AND pass ERC. This way you could also pass a power ground trace inside a signal ground zone fill keeping them separate. It isn't done here but in another job I did so. And it works great (having a 30A load anda thermocouple amplifier on the same board has 'some' ground issues :D)
> > > 
> > > Now, back to the problem at hand: as you can see in the 'good' netlist an 'old' version of eeschema correctly generate the netlist. At least I hope it's correct since the board is in fab:P
> > > 
> > > Current kicad (updated yesterday) gives the 'bad' netlist. For example it list D2 as unconnected. Other components are wrong as well.
> > > 
> > > Also, unrelated, in the module editor trying to enter the attribute editor often segfaults eeschema :(
> > >
> > 
> > Subversion R2005 extracts a good netlist (at least D2 is connected). Will svn update and try again.
> > 
> > Pat
> >
> Confirmed that for this schematic, netlisting stops working properly sometime between R2005 and R2046. Note that, as I posted earlier, to test with this schematic, you have to massage the .pro library entries a bit, because the custom libraries which were used are not directly included.
> 
> On a related note -- the demos subdirectory is great for regression testing, but it could use more examples. I would assume the demos don't all have to be under the same license as the main package, so perhaps the developers could add this example to the demos under Lorenzo's license, and create a policy for accepting more demos.
> 
> Regards,
> Pat
>
Confirmed working in subversion r 2015, broken by changes made in r 2016. Judging by comments, will probably be changes made to GetPin/GetNextPin logic.