Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose additional properties on hole/pad connectors #39

Open
follower opened this issue Jun 27, 2017 · 7 comments
Open

Expose additional properties on hole/pad connectors #39

follower opened this issue Jun 27, 2017 · 7 comments
Assignees

Comments

@follower
Copy link
Contributor

follower commented Jun 27, 2017

For a given connector (from .connectHoles, i.e. holes and pads, as created in ._buildDepthHoles()) we want the following properties exposed (via .userData):

  • Element name (already available via .userData.element?)
  • Pad/Pin name
  • Mirrored? or Top/Bottom Layer? [Not to be specifically handled currently (see here).]
  • Signal name (Is only one signal ever connected per pin?) [see Expose signal name as connector property #40]
@follower follower changed the title Expose additional properties on hole/pad connector Expose additional properties on hole/pad connectors Jun 27, 2017
@follower follower self-assigned this Jun 27, 2017
@follower
Copy link
Contributor Author

follower commented Jun 27, 2017

Viewing in the JS Console the Sparkfun redstick from examples/complex.html as an example:

> brd.connectHoles[66].userData

Object {drill: pad, element: element}

(Note: Not all items in .connectHoles have userData.)

> brd.connectHoles[66].userData.drill

<pad name="4" x="7.62" y="0" drill="1.016" diameter="1.8796" rot="R90"/>

So, the pad/pin name can be retrieved via:

> brd.connectHoles[66].userData.drill.getAttribute("name")

"4"

The parent element (which seems to originate from .userData.drill.elementParent) can be retrieved via:

> brd.connectHoles[66].userData.element

<element name="JP8" library="SparkFun-Connectors" package="1X04_NO_SILK_ALL_ROUND" value="DNP" x="12.7" y="1.27" rot="R180"/>

So, the associated element name can be retrieved via:

> brd.connectHoles[66].userData.element.getAttribute("name")

"JP8"

@follower
Copy link
Contributor Author

Apparently connectors have changed to not be placed on both top and bottom side individually, so it may be unnecessary to specify this in the name with the latest code.

@dave5
Copy link
Contributor

dave5 commented Jun 27, 2017

top and bottom connectors are a premature optimisation. lets just got for a single connector positioned at the mid-plane

@follower
Copy link
Contributor Author

follower commented Jul 3, 2017

It seems that top/bottom connectors are currently treated differently anyway (only the top hole gets the elementParent property added to it):

connector.userData.drill = drills[ i ];

FWIW it's not immediately obvious if there's any Eagle-related functionality that requires two connectors per hole so until we run into anything I can continue with the practice of treating the top connection as canonical.

@dave5 are you able to push your single-connector version of the code? (Assuming I understood you correctly and such a modified version exists.)

@follower
Copy link
Contributor Author

follower commented Jul 3, 2017

Given the primary goal of this ticket is to expose element & pin names for use with #38 it seems like this doesn't actually require additional functionality as these properties are already exposed.

Is there a need to expose these properties by a simpler mechanism than the current approach? i.e.

  • Element name: .userData.element.getAttribute("name")
  • Pin name: .userData.drill.getAttribute("name")

Note that currently the drill property does not exist for all elements in .connectHoles since it is not added to the bottom-side connectors.

Given that we didn't already "know" these values were exposed, I wonder if this suggests at some point we need a better way of implementing/documenting what is stored in .userData?

@follower
Copy link
Contributor Author

follower commented Jul 3, 2017

(Oh, I remember now, I wondered if a stackable Arduino shield style-header (e.g. https://www.adafruit.com/product/85) would be a situation where separate top/bottom Connectors might be required.)

@follower
Copy link
Contributor Author

Once the PRs listed in #38 & #40 are merged this issue (and the two related issues) can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants