KiCad Download Optional Properties

[kr15h]

Adding optional properties for KiCad.

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

// 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"
      }
    }
  }
);

[kr15h]

I am still thinking how and whether it makes sense to do something like this.

const R_1206 = footprint(
  {
    "1":{"shape":"M -0.032,0.034L 0.032,0.034L 0.032,-0.034L -0.032,-0.034L -0.032,0.034","pos":[-0.06,0],"layers":["F.Cu","F.Mask"],"index":1},
    "2":{"shape":"M -0.032,0.034L 0.032,0.034L 0.032,-0.034L -0.032,-0.034L -0.032,0.034","pos":[0.06,0],"layers":["F.Cu","F.Mask"],"index":2}
  },
  {
    kicad: {
      footprint: "EhPrint"  
    }
  }
);

[leomcelroy]

One issue is footprint returns it's argument. So it's still unclear where to store the extra info.

[ducky64]

I'm not super familiar with Javascript conventions (which may be a lot more unstructured), but having designed other DSLs I'd have expected it to return a Footprint object that could be extended with additional fields or functionality.

Also, in terms of priorities, these tend more towards power user features that requires a deeper understanding of KiCad internals (perhaps with the exception of the footprint name) to use. Better component refdesing (#57) would be a much easier gets-much-of-the-way-there solution for hybrid flows.

[leomcelroy]

I'm open to adding a _meta key to components.

I think this

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

is more idiomatic as something like this

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

[kr15h]

I wonder if it would be a good idea to do the same with footprints and components?

const R_1206 = footprint(...);
R_1206.setKiCadProps({...});

let J3 = board.add(...);
J3.setKiCadProps({...});

[ducky64]

Would something like this work?

const R_1206 = footprint(...)
    .withKiCadProps({...});

let J3 = board.add(...)
    .withKiCadProps({...});

(and in concept this can be chained with other properties)

[kr15h]

I like this.

---

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

On Thu, 15 Jun 2023 at 01:02, Richard Lin @.***> wrote:

Would something like this work?

const R_1206 = footprint(...) .withKiCadProps({...}); let J3 = board.add(...) .withKiCadProps({...});

(and in concept this can be chained with other properties)

— Reply to this email directly, view it on GitHub https://github.com/leomcelroy/svg-pcb/pull/61#issuecomment-1592049098, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGHQWLXE65Q3EJS4ZUL53LXLIYF5ANCNFSM6AAAAAAYML7NJY . You are receiving this because you authored the thread.Message ID: @.***>

[kr15h]

So this is more what we discussed previously. I agree with @leomcelroy that this is mode idiomatic. It probably does not make much difference whether the field is called _meta or __meta__, the latter being less prone to future feature interference, presumably. This would allow to add additional properties for Gerber export as well. This could make it easy to target other highly configurable formats without the need of building a loaded GUI for each of them. So now it could look more like this:

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