Part checking with FritzingCheckPart.py

trying the FritzingCheckPart.py script it retons only “Isn’t a Fritzing file and has been ignored in processing the directory” even when I export core parts.

Why has the repo no issue tracker?

Then you have exported core parts incorrectly. It is expecting either an uncompressed .fzpz file like this:

$ ls
NMA0515SC.fzpz svg.breadboard.NMA0515SC_1_breadboard.svg
kdc-nma.pdf svg.pcb.NMA0515SC_1_pcb.svg
part.NMA0515SC_1.fzp svg.schematic.NMA0515SC_1_schematic.svg

$ FritzingCheckPartw.py part.NMA0515SC_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.NMA0515SC_1.fzp

**** Starting to process file svg.breadboard.NMA0515SC_1_breadboard.svg.bak

**** Starting to process file svg.schematic.NMA0515SC_1_schematic.svg.bak

**** Starting to process file svg.pcb.NMA0515SC_1_pcb.svg.bak

File
‘part.NMA0515SC_1.fzp.bak’

This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line 38

or a copy of the core parts directories which are writable (which core parts is not) which is more complex to arrange. You basically need to create a clone of the parts directory in a writable location. I usually ignore that an use .fzpz files.

It does have an issue tracker (although it hasn’t been used in years and I usually ignore it so the point is moot)

reality is that I haven’t updated checkpart in 6 or 7 years because few people other than me use it and as noted, I use it with .fzpz files. I haven’t used the parts directory format in years (and I expect the handful of other folks using it don’t either.) AFAIK there is no documentation on the format of .fzpz files, I know what they look like and can generate one from a part in core parts (or you can edit the part with Parts editor and save it as a new part to get the .fzpz file.)

Peter

Hi @vanepp thanks for the answer. I was looking at the fritzing fork (7 commits ahead) at GitHub - fritzing/FritzingCheckPart, this one has no issues enabled.

I finally got it to work. This is the output for the core part Inductor:

./FritzingCheckPart.py check/Inductor/part.coil_517c33ee17f681ded1beda7291e943af_1.fzp 
File
'check/Inductor/part.coil_517c33ee17f681ded1beda7291e943af_1.fzp.bak'

This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line 45

Warning 6: File
'check/Inductor/part.coil_517c33ee17f681ded1beda7291e943af_1.fzp.bak'
At line 2

ReferenceFile name 

'inductor.fzp'

Doesn't match fzp filename

'coil_517c33ee17f681ded1beda7291e943af_1.fzp'

Warning 19: File
'check/Inductor/svg.pcb.coil_517c33ee17f681ded1beda7291e943af_1_pcb.svg.bak'
At line 9

Height 7.1999998 is defined in px
in or mm is a better option (px can cause scaling problems!)

Warning 19: File
'check/Inductor/svg.pcb.coil_517c33ee17f681ded1beda7291e943af_1_pcb.svg.bak'
At line 9

Width 43.200001 is defined in px
in or mm is a better option (px can cause scaling problems!)

Warning 20: File
'check/Inductor/svg.pcb.coil_517c33ee17f681ded1beda7291e943af_1_pcb.svg.bak'
At line 21

copper1 layer should be at the top, not under group copper0

Warning 25: File
'check/Inductor/svg.pcb.coil_517c33ee17f681ded1beda7291e943af_1_pcb.svg.bak'
At line 46

Silkscreen layer should be above the copper layers for easier selection
in pcb view

That fork was made when I first did FritzingCheckPart back around 2017 and I have no access or control of it. The version on my repo on github is probably in somewhat better shape though. Of those the

Warning 19: File
'check/Inductor/svg.pcb.coil_517c33ee17f681ded1beda7291e943af_1_pcb.svg.bak'
At line 9

Width 43.200001 is defined in px
in or mm is a better option (px can cause scaling problems!)

is (I think anyway) currently an error. Parts in core parts are not necessarily correct when and if we manage to converge on an update to the part file format docs it was my intention to run al the core parts through FritzingCheckPart and correct them, but we haven’t managed to get a part file doc agreed on so far. It is also possible that bug fixes (FritzingCheckPart.py is from2017 when development had stopped, it restarted again around 2019) have made some of the things being flagged no longer apply. It really needs a complete rewrite, but I am so far not all that motivated to do it. I use it constantly and it works for me, but since I wrote it, I can usually tell what it is safe to ignore.

Peter