KiKit should be able to export a bom and pos file

[mayl]

I really like how KiKit allows a pcb processing pipeline to be created where a design can be automatically panelized, and gerbers exported for fabrication. To make this process complete, I think there should also be options for generating a bom and pick and place position file. This way an entire fabrication and assembly package for a design could be generated without any manual intervention. Is there interest in such a feature?

[yaqwsx]

Definitely! In the long term plans, I would like to provide KiKit with a command to generate complete manufacturing data for vendors. So you could call kikit export fabhouse jlc --all or kikit export fahouse gatema --all or kikit export fahouse oshpark to get all the manufacturing data for you fabrication house.

The first step is to be able to export POS files, BOMS. The rest is to implement some glue to rename and organize the files according to the needs of given fabhouse.

[mayl]

Cool, glad to hear you agree! A thought/suggestion I have for these types of outputs is that they should optionally be able to go to standard out instead of directly to a file. This would make it simpler to write a custom, secondary processing step if needed. For instance, I'm learning that many of the kicad footprints do not have a compatible rotation with JLC's assembly service. I'm going to need to write a script to "correct" the disagreeing footprints anyway, if I could take the position file in from KiKit on standard in that would be super convenient!

[yaqwsx]

Might be relevant (I haven't studied it yet): https://github.com/matthewlai/JLCKicadTools

[mayl]

I had looked at that project. I ultimately decided against using it, but it does at least attempt to address the two issues I brought up here: 1) generate a BOM in JLCPCB's preferred format. There are already xsl BOM template for JLC PCB floating around, so generating a BOM with the correct fields seems less of an unsolved problem overall.
2) generate a POS file, in JLCPCB's preferred format and with the appropriate Kicad footprint rotations modified to match JLCPCB.

That project works by having a separate "database" file (just a text file, not actually a database) which maps Kicad footprints to rotation offsets. While I think I understand some of the "practical" motivations for doing things that way, I have some concerns with it as a design. Firstly, it seems to spread the data around to too many places. What happens if JLCPCB, Kicad or this script's database get out of sync? What if they stay in sync but change? Would that break old designs which references the "old" Kicad part, or database/etc. Do you have to re-clone the script from Github to get an updated database (inconvenient)? Also, maintaining the connection between a row and a position offset with a Kicad footprint name seems less direct than it could be.

I think it would be a better design to have a "JLCPCB_ROTATION_OFFSET" field in the actual Kicad component and have the script use that when generating the formatted POS file. This is consistent with the BOM functionality, which already requires that a field be added to components for the LCSC part number. In addition, it more directly ties one footprint in a design to a specific rotation offset, and since Kicad caches footprints with the PCB file, I think it should continue to work even if one of the upstream libraries change. Being able to reliably re-generate POS files for old designs seems important to me. Finally, I like that then the entire design information is captured in one place - the Kicad project.

The disadvantage to storing the offset in the part and not using the separate database for rotation offsets is that the additional parameters are saved in the library. This is probably fine if you maintain your own library, but less convenient if you wish to use the upstream Kicad library. I don't know if the upstream Kicad library maintainers have a policy on this or not, but it would not surprise me if they were uninterested in a bunch of additional footprint parameters to support each PCB fabricator. That could mean you would manually need to add this information to each part in your design.

[Kedarius]

Just my two cents.... I was facing the same issue and I've been wondering, why do you need to rotate the components at all? And as far I've discovered that there is some sort of norm (ISO?) for the default position of the components and that KiCad is a using different one. However I made my own script that rotates the components based on regular expression list and it works just fine...: i.e. "^SOT-*23",180....

But what I am saying that maybe the fix is as simple as adding attribute to KiCad library, but not just because of JLCPCB but maybe because of an ISO standard.... However I may be completely wrong :-)

[yaqwsx]

Interesting, you have link the ISO standard, @Kedarius? I am surprised KiCAD does not follow it...

[mayl]

AFAIK, JLC doesn't follow an ISO standard, they just pick the orientation the parts come in the reel as 0 link.

In general, my experience has shown that ECAD standards are never universal and shouldn't be counted on. Historically I've even seen cases of pin numbers on common packages being "non-standard". Even if we get the Kicad library to be consistent with JLCPCB, there's no guarantee that the next vendor will be consistent with JLC. All this to say, I think being able to define a translation between your design's zero rotation and your assembler's zero rotation is a much more flexible and practical solution than trying to fix everyone's library.

[Kedarius]

Interesting, you have link the ISO standard, @Kedarius? I am surprised KiCAD does not follow it...

I managed to find the post from where I remember it: https://www.eevblog.com/forum/manufacture/jlcpcb-smt-assembly-service-208764/90/?wap2

At a guess, Kicad footprints generally are using the IPC-7x51 standard. Parts are oriented so that pin 1 is on the upper left, or on the left for two pin parts. Rotation from that base orientation is CCW e.g. a +90 degree rotation puts pin one on the lower left.

JLC seems to be using the EIA-481-D standard, or perhaps the IEC61188 standard.

As I am a hobbyist level PCB "designer", I have no clue about these standards or whether the mentioned post is correct or not. However as a person with software development background I find it really stupid to need to know how oriented the components are by default instead of some sort of marking the orientation (i.e. specifying center and pin 1, or pin1 orientation in respect to center....)

Because if JLCPCB would not have the placement preview, I would not be able to position the components properly. The issue is that now there are some parts not available in JLCPCB and I would like to try another assembly service. Probably another rotation values however the PCBWAY assembler did want a fabrication diagram so I hope they will fix the rotations accordingly...

[mayl]

I understand your frustration and agree, it's not ideal, but this is the way the industry is. I think it's best to think about your parts library and your assembler's library as "internal implementation" details and translate between the two as needed. Where things break down is when people try to view the entire library as a public interface that should be fully consistent with everyone else's library. It's a beautiful thought, but just not practical in my experience.

[Kedarius]

I understand what you are saying and I know that all these possibilities with cheap pcbs, assembly "for a few bucks", etc... are great. On the other side if I've had some blog I could post a nice long post called "Adventures of assembling WS2812 with JLCPCB".... It is a RGB led that has mark on the pin 3. I've ordered them like 6 times and 3 times they were assembled in the wrong way... Even though I exchanged like 5-10 emails with JLCPCB every single time. Even sending them screenshot from KiCad, textual description ( pin 3 is on the top left near the capacitor). And now add to the equation that you could want multiple assemblers.... Because JLCPCB does not accept your components so if they do not have it in stock, they just does not assemble it. I have a simple board with ATMEGA328PB and NFC chip. I need a few prototypes, so I check JLCPCB's stock every day just to find a window when they have both.... And if the prototype proves working I may need to create 100-200 of them in the future. That is not suited for JLCPCB so I will need to go elsewhere and solve the rotation issue again...

[klpeders]

@Kedarius Are you sure about "Mark on pin#3"? From what I can see from physical ws2312 devices, datasheet and Kicad lib, everything is consistent. The mark is on Pin#1 (but device is rotated in datasheet), and pin#3 (VCC) is lower left (probably near a cap).

(Kicad)

(WS2812S datasheet http://www.world-semi.com/DownLoadFile/115)

[Kedarius]

Sorry, my mistake. I did not specify that it is the WS2812B, I did not realize that the "b" and "non b" variants differs that much.... But I can assure you, that the notch is on the pin3, I did solve it for every other board :-(

Datasheet: https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf

The KiCad library has it right on the pin 3

And just to add a funny piece of the puzzle, I did order complete assembly in PCBWAY and yesterday they sent a pictures of assembled boards... And there was only one component rotated wrong, you can guess which one :-) However it was mostly my fault because I did not know how to upload the fabrication diagram via their website so I included it in the gerbers zip. So the assembly department probably did not know about it and used only the centroid position file with rotations and .....

[yaqwsx]

Yesterday I used the JLC PCB assembly service for the first time, so I investigated what files are needed. I found out the files are pretty easy to generate. Therefore, I drafted the initial support in #53 - please, try to use it and report both, successes and issues.

@mayl @Kedarius

[yaqwsx]

The basics were implemented in #53 and we have a single fabrication house that we support. I consider this issue resolved.