KiCad export: specify additional optional properties?

[ducky64]

This is pretty low priority and I think can be worked around, but it's a potentially nice quality-of-life feature.

KiCad footprints in .kicad_pcb files have additional properties that may be useful for hybrid flows (e.g., a board with part of the layout defined in SVG-PCB) - primarily in my case the path (example below) which is used match components when updating a layout with a new netlist (matching by refdes also works - though refdes may not always be stable). Sheetname and Sheetfile may also be useful with some hierarchical tools. Would it be possible to allow the user to optionally specify these values in SVG-PCB and have them passed through to the exported .kicad_pcb file?

(footprint "Capacitor_SMD:C_0402_1005Metric" (layer "F.Cu")
  (tstamp 7a15e574-9065-4d61-b319-c2ab7154018a)
  (at 148.5 52.5)
  ...
  (property "Sheetfile" "UsbUart_Cp2102.Cp2102")
  (property "Sheetname" "usbconv")
  ...
  (path "/00000000-0000-0000-0000-00000c010301/00000000-0000-0000-0000-0000165103da")
  ...

[kr15h]

Yes, definitely these optional parameters can be added in a similar way as the library name option in the Download KiCad modal. Can you make a list of properties that you think are of importance?

[ducky64]

Sure.

I think the tstamp and path are most useful when using SVG-PCB in conjunction with a schematic or netlist, since it allows parts to be matched to a netlist by id (instead of potentially unstable refdes).

property "Sheetfile" and property "Sheetname" may be useful with certain hierarchical tools.

In general, KiCad boards seem to preserve arbitrary property fields, though not all are used by KiCad and may not be visible through the interface.

There are also attrs, currently specifying board-only (component not in schematic), exclude-from-position-files (for pick and place), and exclude-from-BoM. In particular, the board-only attr may be useful in a hybrid SVG-PCB + schematic or netlist flow for things like mechanical mounting holes where there is no schematic counterpart, so the component isn't deleted on a schematic update.

In the file, those are:

(footprint "Capacitor_SMD:C_0402_1005Metric" (layer "F.Cu")
    ...
    (attr board_only exclude_from_pos_files exclude_from_bom)

It might also be nice to support an optional user-specified footprint name (instead of the default "SvgPcb:..."), to make it easier to update the footprint from the local library. Though this one can be worked around given some other matching identifier with a schematic (tstamp or refdes), since footprint can be updated from the schematic.

[kr15h]

As for the last point, do you mean library name? It is possible to change that in the current version of the editor. Take a look at the screenshot below. The input field to the right.

As for the individual footprint names, one would change them in PCB code.

I do not see a problem adding general properties such as Sheetfile and Sheetname. Per-footprint attributes could be added as additional properties in PCB-code.

[ducky64]

Footprint name: so that seems to allow specifying a board-wide library name, but not on a per-footprint basis, right? For example, if I had a footprint Capacitor_SMD:C_0402_1005Metric and another one Resistor_SMD:R_0603_1608Metric, it's not something that's currently supported, right? And inferring from names wouldn't support characters that aren't valid in Javascript names, like dashes in Connector_USB:USB_C_Receptacle_XKB_U262-16XN-4BVC11?

[kr15h]

OK, now I got it. Per-footprint could be possible with additional parameters in PCB-code then. Say, an additional field in footprint definition, e.g. kicad-attrs or similar that would contain an object with anything one would need additionally. Will play around with this.--

Krisjanis Rijnieks creative coding. digital fabrication. solutions https://rijnieks.com

[kr15h]

So one way how this could look like is as follows.

let J3 = board.add(
  header_serial_reverse, 
  {translate: pt(IC1.posX+.02, y+.23), 
   rotate: -90, 
   label: 'J3 serial', 
   kicad: {
     footprint: "Capacitor_SMD:C_0402_1005Metric",
     tstamp: "7a15e574-9065-4d61-b319-c2ab7154018a",
     path: "/00000000-0000-0000-0000-00000c010301/00000000-0000-0000-0000-0000165103da"
   }
);

Notice the `kicad` object. It would be passed to the resulting PCB.components array and KiCad exporter would pick it up and see whether alternative and/or additional values are there for replacement/addition to the final kicad_pcb file.

[ducky64]

It might make sense to have the kicad footprint name be specified in the footprint object, since it should be a common property across all instances of some footprint. Or allow both, where if there's a conflict the per-component property overrides the footprint property?

[kr15h]

Yes, having both is the plan. I am not sure where to add the whole board-specific properties.

[ducky64]

What do you mean board-specific properties?

[kr15h]

Properties, such as Sheetfile and Sheetname. I am trying out something like this now.

let board = new PCB();
board.kicad = {
  properties: [
    ["Sheetfile", "UsbUart_Cp2102.Cp2102"],
    ["Sheetname", "usbconv"]
  ]
};

[ducky64]

Oh I see. I'm not sure how useful those parameters are on a board-wide basis, since it means all components must be on the same hierarchy sheet. Though if you already planning to have board-wide KiCad parameters it probably makes sense to add those for consistency and maybe a convenience feature for those with single-hierarchy-sheet boards.

[kr15h]

Hmm. Where would you add them?

[ducky64]

I think your two above examples make sense!

Perhaps like this, but with more syntactic consistency

board.kicad = {
  Sheetfile: "UsbUart_Cp2102.Cp2102",  // fallback / default if not specified on a per-component basis
  Sheetname: "usbconv"
};

const cap0603 = footprint({ ... }, kicad={footprint: "Capacitor_SMD:C_0402_1005Metric"})

let J3 = board.add(
  cap0603,  // inherits the kicad settings from cap0603, including the kicad footprint
  {translate: pt(IC1.posX+.02, y+.23), 
   rotate: -90, 
   label: 'C1', 
   kicad: {
     tstamp: "7a15e574-9065-4d61-b319-c2ab7154018a",
     path: "/00000000-0000-0000-0000-00000c010301/00000000-0000-0000-0000-0000165103da",
     Sheetfile: "MySheet",  // overrides the board-wide sheetfile
     Sheetname: "quack",  // overrides the board-wide sheetname
   }
);

[kr15h]

OK, that makes sense.

[kr15h]

It is developing here as follows.

// Board-wide properties
let board = new PCB();
board.kicad = {
  properties: {
    Sheetfile: "UsbUart_Cp2102.Cp2102",
    Sheetname: "usbconv"
  }
};

and

// Per-component options and board-wide property override
let J3 = board.add(
  header_serial_reverse, 
  {
    translate: pt(IC1.posX+.02, y+.23), 
    rotate: -90, 
    label: 'J3 serial',
    kicad: {
      footprint: "Capacitor_SMD:C_0402_1005Metric",
      tstamp: "7a15e574-9065-4d61-b319-c2ab7154018a",
      path: "/00000000-0000-0000-0000-00000c010301/00000000-0000-0000-0000-0000165103da",
      properties: {
        Sheetfile: "FileOverride",
        Sheetname: "NameOverride"
      }
    }
  }
);

i decided to keep properties separate from other variables in the per-component PCB-code as they are all the same and are expected to be in a certain place in the KiCad board file. KiCad S-Expression Properties docs and Board File Format docs. It makes it easier also to override the board-wide properties this way.