I used the cadquery script (https://github.com/easyw/kicad-3d-models-in-freecad/tree/master/cadquery/FCAD_script_generator) to generate models for JST-XH Connectors.
They can be found at:
https://github.com/poeschlr/KiCadMCAD/tree/master/Connector_JST_XH
@Maui: i have a question regarding licensing of your script.
Within the repos readme you use GPLv3 or CC v3.0, but in the script files you use lgpl v2
Which one should i use for my derivative work?
@Rene_Poschl
thanx for contributing to MCAD library and using my FreeCAD MCAD scripts to generate new models 
I tested some of them and the geometry are fine (I use DesignSpark Mechanical under windows to check STEP geometry)
I just found some color issues on pins, probably during the fusion process…
thanks for reminding me that… I would use GPL2 or Affero GPL3 (which is aligned to GPL2)…
there is still some license aspects to define for the 3D models libraries
http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg16679.html
I’m still waiting for Wayne to adopt an official license for kicad libraries, probably something like gEDA symbol library (GPL font exception)
As a special exception, if you create a design which uses this symbol, and embed this symbol or unaltered portions of this symbol into the design, this symbol does not by itself cause the resulting design to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the design itself might be covered by the GNU General Public License. If you modify this symbol, you may extend this exception to your version of the symbol, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version
Yes the color issues come from the fusion. (I forgot to ask about it in my original post.)
This problem is the reason for the larger wrl’s. I exported them without fusing them. (And used the freecad internal export functionality.)
I will look at your export script later this week. If I get it to run, i will inform you.
The footprint files are the original files included within the kicad library.
(Connectors_JST.pretty)
In the near future i will also include the compact (e.g.: S03-XH-A-1) footprints.
Currently they do not exist within the library.
for the fusion problems have a look here
http://forum.freecadweb.org/viewtopic.php?t=8451#p69489
sometimes it is enough to have a small overlap to remove a fusion/color probs
keep in touch
Maurice
Ok one followup:
I used your original script to export the DIP_8_300 package and get a similar color problem as i have with my files.
Which versions of FreeCAD and cadquery are you using. (Or did i miss something else?)
I tried FreeCAD 0.15 and the nightly builds (0.16). The screenshot is from version 0.16. For cadquery, i use plugin version 0.3.0
I used CadQuery 2.0, never tested on 3.0…
FC 0.15-0.16 should be fine
are you on debian or ubuntu?
tested with CQ 030 (removing close_CQ_Example(App, Gui) from my script) and the dip8 is fine
edit
I also tested your scripts in FC 0.16 windows with CQ 030 (removing close_CQ_Example(App, Gui) from script) and the fusion with color is fine
try: close_CQ_Example(App, Gui) except: # catch *all* exceptions print "CQ 030"edit: I have an issue on building QFP models with CQ 0.30 … I may consider to investigate on it
I’m on Fedora 23.
I will investigate it a bit within the next days.
(Something tells me this is gonna take more time than i originally planned.)
for Debian I remember I suggested a user to use Ubuntu (32b) on VBox under Debian
https://lists.launchpad.net/kicad-developers/msg19935.html
it is a dirty trick, but it solves the issues without having to buy a M$ os
For me it would be faster to use one of our MS pc in our office.
(Develop on fedora, publish with MS. Yes it is painfull, but maybe this will safe me some time.)
btw:
I don’t have the exception under 0.3 but i get one under 0.2
(‘int’ object has no attribute ‘getitem’)
Is it normal that cq version 0.2 prints version 0.1.8 in the console?
(I downloaded the release v0.2.0 from the cadquery github site.)
edit: if there are licensing problems, fedora is at least as bad as debian. (if not worse.)
that was a bug in CQ but it should be have patched
Ok thanks for this detailed information. I will stick to CQ version 0.3
Today i can’t do anything about the color problem. (I’m already at home and don’t want to install a new os on my machine.)
If I have time, i will investigate what exactly causes the problem under Fedora (Find out which lib is at fault.) Maybe it can be fixed.
I will export the XH files on a windows machine tomorrow. If this fixes the color problems i will update my repo.
Regarding your export routine i will use them for my next models. (Probably Molex PicoPlade) If it works there, I will update the XH script and send you the modified scripts.
Thx @maui for the new VRML export script - got it working. 
File sizes of the VRMLs are 10 times smaller now compared to the old way, incredible!!
Still need to get used to the new look of the VRMLs, as their indentation/bracket order is not cleaned up, but it works and that counts.
Absolutely fantastic.
Really cool starting the script and seeing it go through a folder full with STEP files and making the VRMLs… a breeze.
new method: 40MB
old method: 361MB
Now I can wade through the models again and get them up to date and do a fresh export of all of them + a couple of new ones I made in the last 2 weeks for myself.
@Rene_Poschl - those are some nice scripted XH connectors you got there.
It sounds like it didn’t take you long to adapt the CQ scripts to make those, very nice work.
Will have to look into this myself it seems as my current workflow lacks this automation for high pin count/repetitive pattern parts that more or less look the same, ignoring the pins.
Thx for the inspiration!
what I didn’t get working is an automated process to create nice previews/renders of the part(s).
I installed both POVray and LUXrender and they seem to work (luxrender output looks nicer on standard settings, but takes longer) - the problems are the colors, they aren’t communicated - I guess they weren’t ‘real’ materials to begin with, as the (single) part only got one material, a brownish ‘shape’ color.
Anyone got an idea how to solve this?
The FreeCAD 3D viewer seems to be able to deal with part-sub-material definitions… the piece of code that translates the FreeCAD model to a POVray scene not so much. I have a feeling that this kind of concept doesn’t even exists in FreeCAD.
FreeCAD to the left, POVray to the right, materials how they come out of Inventor, didn’t use the script where one applies the standardized materials (will try that next):
[EDIT]
…tried with the standardized materials, but it didn’t help - or I didn’t do it correctly.
I think the problem is the single part… will have to do some reading I guess.
OK… having a go with PoseRay I get this preview for the VRML files (STEP isn’t supported) in the hope of being able to use it as a converter to get the sub-surface-material color information communicated through to POVray I see this:
Arghh… either version has it’s problems:
Anyhow, using the new VRML part and getting PoseRay to use POVray to render it I get this result:
PoseRay comes with command line options, which means it can be automated for batch processing…
@maui
What do you think… ?
modify/fixing the povray-export code in FreeCAD to be able to get sub-part-materials communicated
> FreeCAD > POVray
pro: future proof (no need for VRML models)
con: more work involved I guess and will take longer
adopt your VRML-creation-code to output meshes the way PoseRay expects it
> FreeCAD > VRML > PoseRay > POVRay
pro: probably fast solution to problem
con: needs VRML models
something else entirely
> …
[EDIT]
just for reference the new method VRML model in KiCAD:
@Joan_Sparky have a look here
http://forum.freecadweb.org/viewtopic.php?f=3&t=10499&p=113553&hilit=macro+povray#p113553
the problem is related with the standard FC macro of Povray that doesn’t read colors of fused parts… I opened a ticket…
anyway Marmni did something that works with colors and STEP fused objects
I have updated the macro to add material properties to VRML in a more polished way… I added the materials at the top of the VRML file, and the I added USE “Material Name” inside the VRML …
https://github.com/easyw/kicad-3d-models-in-freecad/blob/master/exportVRMLwColors/exportPartToVRMLwMaterials.FCMacro
adding Material Properties to VRML will add a small 10% on size but will give you a nicer view, particularly in the new VRML raytracing 3d-viewer that Mario @kammutierspule is developing and that will be (hope) merged quite soon in the main dev-branch of kicad (this branch has also pivot center of rotation selectable)
VRML in OpenGL view of KiCad
I was about to say that it is a bit shiny…
but I found this picture and it looks very close!
Nice render!
Would be possible to render (blender?) a similar shot to compare?
With one directional light on the top at 0.7 intensity (and if possible) a front omni light (without shadows) on the front
Ok, will have a go with that one.
If I scale the object again (after exporting it to VRML) I can size them relative to the camera/light position and make them all appear the same… so all I would have to do find a camera/light position that works and scale the models accordingly…
Sounds like a plan, he?
I might need to adjust my material properties down the road to get those additional attributes in there, but I’ll see how I go first.
PS: very nice render there. Good job @kammutierspule!
this macro
