I have been using the JST JQ 3 pin connector in a project, but I have been annoyed that it does not have a 2 or 4 pin variant, so I modified it to create my own. I have since learned that the receptacle of the JQ connector is the same as the XH connector (which is what I am actually using in my IRL project).
I shrunk and extended the SVGs in Inkscape and then ran the files through FritzingCheckPart.py and dealt with all the errors. I have tested importing them into Fritzing and confirmed all pins are working as expected, at least in breadboard and schematic views (haven’t used PCB view at all yet)
I would like to add these to the core parts bin, but first would like feedback on packaging, any files to rename, or any issues in different projects. I believe these parts could adequately replace the JQ part in core as they have directly been derived from it.
Either of a google search of the form “fritzing part jst xh connector” or jst xh connector in the forum search bar would have brought up this post which already has these parts.
Thus preventing you from reinventing the wheel. Always do a google search for already available parts before making new ones.
Thanks, that was a simple fix - I had changed the layer in Inkscape but apparently only the label - this means that in the XML it carried the old group name (autogenerated) and has an additional tag <inkscape:label>copper0</>. FritzingCheckPart.py did not flag this as it only mentioned that copper0 is defined in the FZP file. I also checked across the other files for the same mistake (thanks git-grep). JST-B2B-XH-A.fzpz (7.2 KB)
If you save the svg (with File→save as) as plain svg that will eliminate all the Inkscape additions (Inkscape complains about data loss in the save but it turns out OK in Fritzing.) It may be that I didn’t check for both copper groups in FritizingCheckPart.py, I think I have run across cases of a copper group missing that didnt’t get flagged before.
Gotcha. I don’t think I’ll bother removing the other tags unless there’s a problem. I took a peek at some of the files in core parts and there are some with Inkscape and/or Adobe Illustrator tags, and it doesn’t seem to affect anything in Fritzing.
Question regarding FritzingCheckPart.py and XML checking for parts: I see that in the fritzing-parts repository there is an fzp_checker.py - is this doing a similar job to FritzingCheckPart.py, and is one preferable to use over the other?
I have been thinking of moving FritzingCheckPart in to fzp_checker.py but haven't yet had time to do anything about it. FritzingCheckPart has more checks than I see in fzp_checker.py and is still what I use but as I wrote it I count as biased . Not enough people use FritzingCheckPart (or make parts in general) to motivate me to do much currently. Try them both and use which ever works best for you is probably the best bet.
fzp_checker.py in the parts repo is my approach to validated parts.
It replaces the previous scripts, to unify the call parameters, and can be used as package in external programs.
It runs automatically when integrating a new part to the repo.
Main differences to FritzingCheckParts.py as far as I know:
fzp_checker can be used standalone, or as python package.
When used as a package, it should return a report that contains the error messages and the xml nodes that contain the problem.
In standalone mode, it can check svg, fzp and fzpz files.
It will not modify the files, unless the --fix option is passed.
When using the fix option, it will keep as much of the document untouched as possible, so the files can be diffed with git.
When checking a svg file, it will also lookup all parts that uses these, and check them, too.
@vanepp I am not sure if there are still checks FritzingCheckParts that are missing in fzp_checker. Last time we checked, the main problem was that the fzp_checker was more strict (or warned about non-problems , depending on how you see it)
I think we could add a relaxed-mode, for example that allows for invisible connectors?
To reformat files we use scour. Reformating is not always wanted, for example if you want to merge changes to a repo.
I’ll have a look at fzp_checker when I finish up python_partsfactory.py. svgpathtools looks to be working at calculating viewbox (still some issues but I have a work around) but still some work and not much time currently.
. Not enough people use FritzingCheckPart (or make parts in general) to motivate me to do much currently. Try them both and use which ever works best for you is probably the best bet.