KiCad nightly (v5.99): New schematic and symbol library file formats are now the default

There is no technical reason. All of the internal data structures in the schematic and library editor code base are currently predicated on this behavior. Changing this would most certainly break the legacy symbol library file format which is out of the question. Implementing this would require deprecating writing to the legacy symbol library file format and making all legacy symbol libraries in the symbol library table read only. I don’t think this would be a trivial change in the code base. At some point this will happen but it will take some time. Once this is done, the naming behavior can be changed.

3 Likes

@stambaughw After checking the new format in the nightly build, I do have few questions.

If one wants to separate the “visual representation” of the symbol (managed by symbol editor) from the properties (assuming it is managed by eeschema library loader), I’m able to load the following .kicad_sch file just fine:

(kicad_sch (version 20200512) (host eeschema "5.99.0-unknown-4efed4b~101~ubuntu18.04.1")

 (page 1 1)

 (paper "A4")

 (lib_symbols
   (symbol "CAPACITOR_CERAMIC" (pin_numbers hide) (pin_names (offset 0) hide)
     (polyline
       (pts (xy -1.27 0) (xy -1.016 0))
     )
     (polyline
       (pts (xy -0.889 1.905) (xy -0.889 -1.905))
       (stroke (width 0.254))
     )
     (polyline
       (pts (xy 0.889 1.905) (xy 0.889 -1.905))
       (stroke (width 0.254))
     )
     (polyline
       (pts (xy 1.27 0) (xy 1.016 0))
     )
     (polyline
       (pts (xy 1.905 0) (xy 2.54 0))
     )
     (pin passive line (at -3.81 0 0) (length 2.54) (name "1") (number "1"))
     (pin passive line (at 3.81 0 180) (length 2.54) (name "2") (number "2"))
   )
 )

 (symbol (lib_id "CAPACITOR_CERAMIC") (at 77.47 85.09 270) (unit 1)
   (uuid "00000000-0000-0000-0000-00005e2185db")
   (property "Reference" "C2" (id 0) (at 80.137 82.7786 90)
     (effects (font (size 1.524 1.524)) (justify left))
   )
   (property "Value" "C1608X8R1E104K080AA" (id 1) (at 66.04 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Footprint" "Capacitors:C0603" (id 2) (at 50.8 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Datasheet" "https://product.tdk.com/info/en/catalog/spec/mlccspec_commercial_hightemp_en.pdf" (id 3) (at 48.26 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Supplier" "Digikey" (id 4) (at 63.5 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Supplier Part Number" "445-2500-1-ND" (id 5) (at 60.96 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Manufacturer" "TDK Corporation" (id 6) (at 58.42 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Manufacturer Part Number" "C1608X8R1E104K080AA" (id 7) (at 55.88 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Description" "CAP CER 0.1UF 25V X8R 0603" (id 8) (at 53.34 85.09 0)
     (effects (font (size 1.524 1.524)) hide)
   )
   (property "Capacitance (Farad)" "100nF" (id 9) (at 80.137 85.2678 90)
     (effects (font (size 1.27 1.27)) (justify left))
   )
   (property "Tolerance (%)" "±10%" (id 10) (at 73.66 96.52 0)
     (effects (font (size 1.27 1.27)) hide)
   )
   (property "Voltage Rated (Volt)" "25V" (id 11) (at 80.137 87.5792 90)
     (effects (font (size 1.27 1.27)) (justify left))
   )
 )
)

Is this the right approach?

Now, if one wants the properties of this capacitor to also be coming from the symbol editor / pre-loaded before it is placed in eeschema, I am trying to extend the “CAPACITOR_CERAMIC” symbol with properties:

(kicad_sch (version 20200512) (host eeschema "5.99.0-unknown-4efed4b~101~ubuntu18.04.1")

  (page 1 1)

  (paper "A4")

  (lib_symbols
    (symbol "CAPACITOR_CERAMIC" (pin_numbers hide) (pin_names (offset 0) hide)
      (polyline
        (pts (xy -1.27 0) (xy -1.016 0))
      )
      (polyline
        (pts (xy -0.889 1.905) (xy -0.889 -1.905))
        (stroke (width 0.254))
      )
      (polyline
        (pts (xy 0.889 1.905) (xy 0.889 -1.905))
        (stroke (width 0.254))
      )
      (polyline
        (pts (xy 1.27 0) (xy 1.016 0))
      )
      (polyline
        (pts (xy 1.905 0) (xy 2.54 0))
      )
      (pin passive line (at -3.81 0 0) (length 2.54) (name "1") (number "1"))
      (pin passive line (at 3.81 0 180) (length 2.54) (name "2") (number "2"))
    )
    (symbol "C1608X8R1E104K080AA" (extends "CAPACITOR_CERAMIC")
      (property "Reference" "C" (id 0) (at 0 4.064 0)
        (effects (font (size 1.524 1.524)))
      )
      (property "Value" "C1608X8R1E104K080AA" (id 1) (at 0 -11.43 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Footprint" "Capacitors:C0603" (id 2) (at 0 -26.67 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Datasheet" "https://product.tdk.com/info/en/catalog/spec/mlccspec_commercial_hightemp_en.pdf" (id 3) (at 0 -29.21 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Supplier" "Digikey" (id 4) (at 0 -13.97 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Supplier Part Number" "445-2500-1-ND" (id 5) (at 0 -16.51 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Manufacturer" "TDK Corporation" (id 6) (at 0 -19.05 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Manufacturer Part Number" "C1608X8R1E104K080AA" (id 7) (at 0 -21.59 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Description" "CAP CER 0.1UF 25V X8R 0603" (id 8) (at 0 -24.13 0)
        (effects (font (size 1.524 1.524)) hide)
      )
      (property "Capacitance (Farad)" "100nF" (id 9) (at 0 -3.81 0))
      (property "Tolerance (%)" "±10%" (id 10) (at 11.43 -3.81 0)
        (effects (font (size 1.27 1.27)) hide)
      )
      (property "Voltage Rated (Volt)" "25V" (id 11) (at 0 -6.35 0))
      (property "ki_keywords" "100nF 25V 0603" (id 12) (at 0 0 0)
        (effects (font (size 1.27 1.27)) hide)
      )
      (property "ki_description" "CAP CER 0.1UF 25V X8R 0603" (id 13) (at 0 0 0)
        (effects (font (size 1.27 1.27)) hide)
      )
    )
  )

  (symbol (lib_id "C1608X8R1E104K080AA") (at 77.47 85.09 270) (unit 1)
    (uuid "00000000-0000-0000-0000-00005e2185db")
    (property "Reference" "C2" (id 0) (at 80.137 82.7786 90)
      (effects (font (size 1.524 1.524)) (justify left))
    )
  )
)

The symbol lib reference would only overload the “Reference” field, right?

Unfortunately, I’m getting this error:

Error loading schematic file …
No parent for extended symbol CAPACITOR_CERAMIC in file …
line: 29
offset: 45

How would one manage this?

Thanks!

Hi @stambaughw Wayne,

Some months ago I opened a feature request about the kicad_wks to be inserted in the new schematic/layout file format.

When we send or publish a project, the worksheet can be easily forgotten and lost for future distributions.

Is there a chance in V6 that the worksheet is embedded in the kicad_sch and kicad_pcb files the same way as the symbols and footprints? Thanks.

1 Like

For reference, here is the issue in gitlab (I just thumbs upped it):

1 Like

@eeintech Inheritance cannot be used in the library symbols embedded in the schematic. The “extends” keyword is causing the failure. Inheritance can only be used in symbol libraries.

Please do not use “eeschema” as the host name for hand edited and script generated schematics. Change it to “hand-edited-by-me”, “my-leet-hacker-script”, or something similar. The “eeschema” token is reserved for by Eeschema formatter and is ignored by the parser. This way when you file bug report with your broken file, it is obvious to developers that this it was not generated by Eeschema. This applies to all KiCad file formats. This has caused countless hours of wasted KiCad developer time only to discover that it was due to files generated outside KiCad.

2 Likes

Possibly, but doubtful. The are a lot of higher priorities for V6 so most likely this wont happen until V7 development.

2 Likes

@stambaughw Thanks for your answer, it makes sense that inheritance should only by on the library side. Can I actually create a part with this syntax and be able to open it in the Library Editor at this time?

I am sorry for the hostname… I just modified the middle section of the file, making it obvious I did it by hand. I did not know it had so much importance.

Thanks for your answer, Wayne.

@eeintech You can define symbol libraries with the “extends” keyword and open them in the symbol library editor assuming you haven’t broken anything.

The host name is only important if you file a bug report. This way the development team knows that your file wasn’t created by KiCad and we don’t waste time looking at the formatter code for bugs that do not exist.

@stambaughw
Is the sheet template not stored in the schematic file?

What do you mean by “sheet template”?

@eelik
I mean the titleblock, the frame in the schematic, worksheet template.
I hope it is clear what I mean.

That’s what was referred to earlier:

The worksheet template is an independent file now. The default one is somewhere in the KiCad installation, you can make your own.

Not yet. See discussion above :wink:

Oops. Sorry I should have read the whole threat, before posting. :man_facepalming:

but @hildogjr talking about MIRROR - it should not take much work :slight_smile:

Other way you can do about this is hash the whole file with your “none-public” hard code value/key from the kicad source code itself. This will make it harder the people to fake it, instead of just a hard fix value “Eeschema”. You can use any type of hash MD5, SHA1 … it not that importance, but good enough.

What would the benefit of a mirror be?
Having something on gitlab really only benefits users if they can use gitlab to make issues or pull requests. However, these are the features we would need to remove from the mirror (which i doubt is part of gitlabs feature set).

The core git feature set would be all that remains but git really does not care where you have the remote. You don’t even need an account for read access to the github repo. And a mirror would by definition also always be read only so …

I bet you right. Only benefit I see is: get more visibility to more people, and in cast a failure on one side, other should be fine. I mean failure like company shutdown (which rare).

Does this mean that, to properly print a random hierarchical schematic sheet in a project, i would need to find the root file project and “back-annotate” with the data found in it?