When writing software a key part of the development workflow is looking at changes between files. With version control systems this process can get pretty advanced, letting you see changes between arbitrary files and slices in time. Tooling exists to do this visually in the world of EDA tools but it hasn’t really trickled all the way down to the free hobbyist level yet. But thanks to open and well understood file formats [jean-noël] has written plotgitsch to do it for KiCAD.
In the high(er)-end world of EDA tools like OrCAD and Altium there is a tight integration between the version control system and the design tools, with the VCS is sold as a product to improve the design workflow. But KiCAD doesn’t try to force a version control system on the user so it doesn’t really make sense to bake VCS related tools in directly. You can manage changes in KiCAD projects with git but as [jean-noël] notes reading Git’s textual description of changed X/Y coordinates and paths to library files is much more useful for a computer than for a human. It basically sucks to use. What you really need is a diff tool that can show the user what changed between two versions instead of describe it. And that’s what plotgitsch provides.
plotgitsch’s core function is to generate images of a KiCAD project at arbitrary Git revisions. After that there are two ways to view the output. One is to generate images of each version which can be fed into a generic visual diff tool (UNIX philosophy anyone?). The documentation has an example script to help facilitate setting this up. The other way generates a color coded image in plotgitsch itself and opens it in the user’s viewer of choice. It may not be integrated into the EDA but we’ll take one click visual diffs any day!
I use daily AtutoVue, which can visualy diff any file (pdf, gerber, etc. …)
Can you give me some link pls? I didn’t find it. Thanks :)
Oracle autovue i think he means
Still waiting to have an upstream difftool (https://bugs.launchpad.net/kicad/+bug/1774887). I even wrote a prototype to show that KiCad allows graphic diffs without using external libraries (https://forum.kicad.info/t/net-aware-pcb-diff-tool-kicad-python-demo/12270)
Nice job.
Awesome sauce
Still waiting for an upstream implementation (https://bugs.launchpad.net/kicad/+bug/1774887). I even wrote my own board-diff tool to show no external dependencies are required to implement it (https://forum.kicad.info/t/net-aware-pcb-diff-tool-kicad-python-demo/12270)
TBH Altium build-in VCS sucks, because there is no real way to contribute on the same file simultaneously and the merge the results. And the project files being saved as binary doesn’t help.
I have always thought that a clean way to diff binary files would be to generate text-based summaries (of configurable detail level), and then compare the summaries with a standard diff tool. If the reporting format were standardized (along with the order of corresponding file sections/components), you could diff across a wide variety of binary files, even from different vendors.
For example, I could envision a PCB file summarizing tool that spit out something like a BOM, but with schematic page and position coordinates. If the same summary output format was supported by KiCad, OrCad, or Altium plug-ins or add-ons, you could diff PCB layouts even as the design migrated across different software platforms.
This is unlikely to be supported by the vendors themselves, as vendors prefer migration tools operate in a single direction.
This is a technique I developed for use with PDFs using Adobe Photoshop. The advantage of Photoshop is the ‘was’ condition can be nudged to like up with the ‘now’ to eliminate false differences from users making minor and meaningless tweaks. I used it with CAD documents and I swear there are some users who will grab every single thing and move it .015 inch just because. The other advantage to mixing comparison with editing is that it can cope with details moved to other sheets or, in mechanical drawings, have their scales changed. Best of all, I could select based on color, convert it to a selection, and then stroke the result with a fat blue pen. If there was a comma changed to a period it was visible even if the actual change at screen scale was less than one pixel in size.
Perhaps great minds think alike – black background, red and green. I used differing percentages of transparency to produce a nice baby-puke yellow where they overlapped.
The other great advantage of pixel based comparison is that any picture format can be a basis, so a hand-drawn schematic is fair game, as well as skewed scans or faxes; all of them can be transformed. At that point it is far from automatic, but it does allow the user to adequately document the differences, including keeping as many versions in one file for mutual comparison as desired, which means a much easier job of tracking when a feature or error was introduced.
Line up, not like up.