I recently wrote a brief tutorial for how to render and share Altium designs in the browser using GitHub and GitLab. I’d love some feedback.
Also happy to try and answer any questions about this on general git + circuits questions.
Demo project here
3 Likes
I’m going to be interviewing Kyle on The Amp Hour later in the summer, I’m looking forward to seeing more like this! Also, pushing him to do more KiCad stuff! 
1 Like
Thanks for the shout out, Chris! Can’t wait.
I’d love to add support for KiCAD if there is demand. We’re developing an open JSON CAD file, which I’ll document a bit in the coming weeks. The idea is that it should be fairly easy to add new parsers for other CAD tools to generate the same intermediate file format (similar to what Upverter was doing a few years ago before they dropped it). If anyone is interested in digging in with me send a DM or feel free to reply.
Did Upverter do something like this?
\https://blog.upverter.com/2011/10/28/import-and-export-upverter-open-json-file-format-and-search/
This is really neat!
So the .githook runs locally before you push to create svgs? And then the diff magic is on github/gitlabs side?
That would be cool for KiCad, as it can export both the PCB and schematics as SVGs natively!
But right now only the PCB side of that can be scripted! Schematic plots can’t be scripted yet 
The only downside I can think of with this approach is potentially it generates a lot of artifacts. Especially if you wanted to do it for the board layout, and were making an svg per layer.
@LukeBeno Right, there are pros/cons to a lot of file formats, like Altium’s pipe-delimited format, Eagle’s XML format (now closed source packaged with installer), KiCAD’s ASCII format (possibly based on gEDA?). We wanted something that was well-supported by many software libraries and had a relatively intuitive hierarchy, so landed on a JSON format. It’s very similar to what upverter was doing before they closed it. It’s frustrating, but we believe companies using proprietary file formats as a tool to increase switching cost for users is one of the big issues destroying progress in hardware design.
@gregdavill Thanks! Yeah, that’s right. In future versions we can build it as a GitHub application so that the conversion is run in the cloud so that you don’t have to commit the svg artifacts. An svg per PCB layer is a neat idea, but we would probably build the layout into a single SVG and let the renderer handle toggling layers on/off. We can also edit the script to move the svgs into a .allspice directory. Actually, one of the next steps we’ve been considering is automated documentation generation, so managing all of these files could become important.
when did eagles xml format go closed source?
The Eagle format used to be documented and published, but has since been removed. It’s still an XML format as I understand.
I stand corrected, the eagle spec is still packaged in Eagle/doc/eagle.dtd
yep, its in the dtd and its under a CC license. i wrote a parser using it myself a few weeks ago.
Generally, I wish the KiCad team (or really ) would take this sort of thing on. Not because they’re better suited to it, but because commercial entities even at their best, may have reason to close off later. I’m sure Kyle and his team will do a good job of the JSON format, but if an investor requires that they close it in the future, his hands may be tied (pure hypothetical). Open source projects have the advantage of not needing to close off later…but that also means there’s less reason to update later, as well, which is part of the problem. Anyone want to parse some KiCad files from the 90s??? Yikes!
I agree with you on this, was just mentioning it more to see if it was the same effort or different one the upverter side. I think upverter’s efforts have run their course and you’re 100% right about development from a more agnostic party instead of one that is perversely motivated to tip the “open” standard in their favor.
In a lot of ways, the whole topic feels to me like fools errand or a perpetual game of cat and mouse. Clearly we’re all tribal in our own fiefdoms, I don’t see the motivation to change this. One does need to ask, is the KiCad development team going to get more traction from a new open file format or adding other kickass features to make it compete head to head with a different pro-tool.
I don’t know the answer, I just offer my opinion: open formats don’t change my personal day to day operations at all. I can see where it would make a tool like All Spice cross compatible with many different CAD tools.
Yes, I think this is the most likely outcome. It will be both a blessing for a company like Allspice wanting to take this on, as a ‘moat’ against others who would want to step on the territory later; it will also be a curse because…well…file formats suck. Whack-a-mole, for the rest of their days
Did anyone post the XKCD comic about standards yet? If not, here we go:
Both of these 
USB Type-B 4 life!
Yeah, even for All Spice, it seems like: pick the format that:
- has a big market
- has customers willing to pay money for services (ie medium to large businesses)
- has history of acquiring enhancement tools and rolling them into a product.
Altium easily checks all of those boxes (back to Luke’s feifdom).
But really it is cool to support KiCad,the use of that tool is growing for sure and I think something like Eagle for example is flat/shrinking.
Ha, we came to that same conclusion, but just can’t find a way around a new format. To your point many of these formats are carrying legacy support from 30 yrs ago, and a lot of code just isn’t written that way anymore. The folks at Upverter did a really great job of building out that project, and I’m sure they would’ve loved to see it go another way.
Maybe I missed it but is this conversion/standard public already? I am certainly interested.
Maybe I missed it but is this conversion/standard public already? I am certainly interested.
The CLI tool to do the conversion for Altium Schematics to JSON and/or svg is packaged in our diff application, which we’re providing totally free: https://www.allspice.io/download
There’s some info on how to use the CLI in the blog post I linked in the initial post.
If you’d like a direct download for just the CLI tool, send me a DM and I’ll get something to you.
We still don’t have 100% coverage for all of the schematic data (for instance, embedded images are not included), but all components, nets, and traces are included in the JSON. We should have initial PcbDoc support by early next week. Over the next several weeks we’ll work on expanding coverage and documenting the JSON format for review from the community.
Ah, I see, I’m mainly interested in some public “standards” or open source conversion tools I suppose. Looks like Upverters was released under an Apache license at one point, so someone could take up the reins: https://github.com/ljmljz/schematic-file-converter
1 Like