Sharing CDFs

[Jason]

Anyone up for sharing custom CDFs?

Just since the editor is so damned clunky it takes ages to
get new parts entered in and it's daft for us all to re-invent
wheels.

[phonoplug]

Unfortunately thats probably easier said than done.

I went through my CDF library recently having a cull of all the useless ones I presume it originally came with. A couple of jobs later I found they all re-appeared. It turns out that when you save a transfer file, it saves a complete copy of your CDF library in it (not just the items used in the job). Very inefficient and pointless. Worse still, every time you open a transfer file, it decides to go through and compare the CDF library saved into the transfer file with the live system library. Anything found missing in your live library is added back in [message: "Refreshing CDFs"]. Who knows what happens if the two have different items with the same name...

The solution was to go through all the transfer files and delete the CDF data at the end. Took a while though to go through about 50 of them. THey still work fine without the CDF data in them, though once you save them its added back in of course.

So anyway, the long and short of it all is that it is probably not as easy as you think to "share", unless you are starting out afresh and take someone's complete library (I have done this for a couple of people when getting them up and running).

[Jason]

Yes, collisions could be a problem, I'll give it a try and see what happens.
But if things just get merged back in when unseen that would seem to
make the problem of everyone building up big useful libraries easier than
what you were trying to do (having a clear out).

If a few people are willing to share some of the CDFs then I'd be
grateful as I've not been up and running for long.

[phonoplug]

I guess you're right there. Some other things to consider then:

Everyone will have an SO-8, an R0603 etc but will probably have tweaked them from their original state, to work reliably with their machine, and the specific parts they commonly use (you can get quite a bit of variation from one manufacturer's SO-8 to anothers, for example). So for all these parts, you'd need to work out how to 'keep' your own version.

Secondly, and I know this for sure, everyone will have different optimum 'threshold adjustment' values that suit their machine (ie its illumination ring's light output), and the ambient light in the environment where the machine is situated. So even if a bunch of people starting out from fresh share the same CDF library, they will end up needing to tweak the 'threshold adjustment' for each item to suit their machine.

Don't mean to sound negative in all of this, but its never as simple as it sounds when an RV is involved!

[Gopher]

I think I still have a copy of all of mine and I'm happy to share it, of course there is another issue or two beyond those Phono mentions - Naming conventions.
Many people will almost certainly have used package names that refer to the part they were using, whatever bizarre name the CAD software gave that package or a manufacturer specific non-EIA name. Sorting through all that could take a while!
Here are some I know I used as examples:
$Tanko_A_M : Tant Case A which could also be called 1206E or 3216, origins - BOM used for inputting data when I was new to the whole thing.
GF1A : Refers to a DO214-AA case GF1A diode, critically in this case not all DO214's are the same height and GF1A's are quite tall, you don't really want your device slammed into your board with excessive force.
SO8 or SO-8 ?
induc - refers to an inductor/choke whose datasheets etc make no claim as to any standard package type this device might belong. Appears to a common thing with this device type.

One thing I certainly learnt was do my utmost to maintain a consistent naming scheme and that is what I try to do on our new system. Of course in that case its somewhat easier as the recipes use part numbers from the database where I must first define them. If one was borrowing others CDF's it would almost certainly be worth viewing them on a different machine first to check what they are.
There is also the possibility the definition is less fussy  than you, for instance I certainly placed a device with one pad larger than the others like the one in your other thread, but I don't recall going to much effort defining the part accurately or experiencing any issues with alignment afterwards. Then there are parts for which no proper definition was ever made and instead "Quick Sizes" was used, this was a solution beloved by VSMT staff that I did use for a while but personally I liked my recipe renders to look like the finished products which this does not achieve.