Connector documentation, created in a v7.0.11 schematic, isn’t rendering the same in KiCad v8.0.8 schematic. The primitives used were “Place⇾Add Text Box” and “Place⇾Add Rectangle”.
This mapping is done on multiple sheets to provide mapping of signals between a vendor’s board and our KiCad design. We suspect the vendor rushed their design and the mating connector mapping is backwards for customers using this interface. Documenting this mapping solves a number of problems for our design and manufacturing documentation.
Is there a better way to create this type of tabular text design documentation in the schematic?
I highlighted the text boxes for better clarity for how this table was created using primitives available in the eeschema tool.
Repairing this by hand will consume non-trivial time to fix, especially if this issue might surface again with a future software update. This is why I’m bringing it up and asking here.
Thoughts? Suggestions? Minor future schematic software fix?
Is there a better way to create this type of tabular text design documentation in the schematic?
Depending on your time schedule you could wait a little and leapfrog the v8 version. The upcoming v9 will natively support tables, which would cover this sort of usecase. Nevertheless much work, as you would have to manually fill the table cells (no import from text/csv file currently).
regarding a software fix: only if you open a gitlab issue (including example project). But I don’t know how much effort would go into this, as v8 is nearly at the end of development and v9 is already looking around the corner.
Suggestions
While I must admit that the original (v7) table looks really good I tell my colleagues to resign from too much polishing the schematic. It’s mostly not rewarded by the customer, takes working time in the first place and sometimes (as in your case) later working time if something unusual/special was done. I had used a one simple textitem (maybe textbox), without the horizontal dividing lines and the alternating background colors.
At least it looks like you have used the original kicad font, which avoids transfer problems between kicad installations on different computers.
I see your points. We are a small shop, so basically we are the customer. We are subject to more stringent regulatory documentation requirements for high reliability (medical, aviation) type applications, as opposed to commercial applications which focus more on cost and delivery schedule than reliability.
I pulled the latest nightly, and sure enough there is a “Place⇾Draw Tables”. I tried it and it mostly works, but needs significant improvements. The good news is, the tables designed in v7 are once again aligned correctly in the v9 presentation! (I can ignore it for now) ⇒
It might be a nicer solution if KiCad tables could be done in LibreOffice Writer or Calc (or MS Word/Excel) and imported cross-platform style (OLE/COM?) linked into KiCad schematics. This way, documentation exists in only one place for future updates, which is a better documentation design practice. Linkage is almost mandatory for “update fields” data needing to be refreshed as it changes in the original documentation.
Of course, I’d want a copy of the table stored in the schematic for rendering tables if the original document moves or disappears. If Python libraries exist for this sort of linkage, cross-platform, this might be a faster and more flexible way to solve this issue and generally allow KiCad software professionals to focus on electronics and PCB design Documentation. This might help KiCad developers avoid wading into the general documentation business. And if OLE (or some other cross-platform solution) is used, hopefully Office documentation can include KiCad design/rendering for other office documents requiring KiCad design information. I mention LibreOffice because however LibreOffice solves this issue may be cross-platform, like KiCad allowing both to share the same cross-platform documentation communication code. Less effort for all involved!
It also just occurred to me that COM/OLE object linking and embedding will allow more complex documentation for design of things like 5th order elliptical filters, or maxwell’s equations as needed to describe what formulation is being solved by the circuit and perhaps relat it back to KiCad/NGSPICE simulation.