Processing Jumpers and Loops, Plus Processing Wires inside the Table as Edges

[tobiasfalk]

Here I started to implement Jumpers, and a new way of drawing Wires inside the Wire table.

• https://github.com/wireviz/WireViz/issues/350
• https://github.com/wireviz/WireViz/issues/352 https://github.com/wireviz/WireViz/commit/6610f515de0659a5a836805c5c0a8eebe459817e

Currently, only the Black circles are done and nothing else. See ex15.png Ps. And now even the right branch

Edit: Ex15:

Ex16:

[tobiasfalk]

Now everything from #350 is implemented.

[tobiasfalk]

Syntax:

connectors:
  X1:
    type: Molex KK 254 # more information
    subtype: female
    pinlabels: [GND, VCC, RX, TX, GND, VCC, GND] # pincount is implicit in pinout
    internal_shorts: [[1, 5, 7], [2, 6]]
    internal_shorts_color: [PK, RD]
  X2:
    type: Molex KK 254
    subtype: female
    pinlabels: [GND, VCC, RX, TX, GND, VCC, GND]
    internal_shorts: [[1, 5, 7], [2, 6]]

[tobiasfalk]

New Syntax:

connectors:
  X1:
    type: Molex KK 254 # more information
    subtype: female
    pinlabels: [GND, VCC, RX, TX, GND, VCC, GND] # pincount is implicit in pinout
    shorts:
      SH1:
        pins: [1, 5, 7]
        color: PK
        manufacturer: WireViz
        mpn: 42XCD42A5
        description: shortPart
      SH2:
        pins: [2, 6]
        color: RD
        manufacturer: WireViz
        mpn: 42XCD42A5
        description: shortPart
        length: 42

[tobiasfalk]

[tobiasfalk]

ex16:

[kvid]

I'm sorry that I've not yet had time to play with this PR, but it seems to work as proof of concept for the #350 discussions.

• I suggest that you activate "convert to draft" while this is work-in-progress (I do forget that with my PRs also sometimes).
• Be aware that your latest syntax expansion probably will need coordinaton with changes in #251 that is first in line for merge into dev.
• The way you want to combine internal shorts and loops, might also need a discussion in #350 because I fear it will be too complicated for the simplest use cases.

[tobiasfalk]

I mainly have problems with the bom and how I add the shorts to the bom

[kvid]

I mainly have problems with the bom and how I add the shorts to the bom

Have you considered making the additional components list be a union of shorts and explicitly specified entries, instead of having a separate list for shorts? Then adding to BOM could be handled equally as well.

[tobiasfalk]

@kvid @martinrieder could you look at the new syntax in ex15 & 16?

[tobiasfalk]

Overall question is if the syntax is acceptable? If so Checks and other things can be done.

[martinrieder]

@tobiasfalk wrote:

Overall question is if the syntax is acceptable?

I would prefer a solution that does not require using loops or shorts in two different locations. Alternatively, I suggest to use a reference key instead for both, since designators have to be unique anyways. It will also avoid the situation like in ex15 where loops and shorts got unintentionally mixed up.

Overall, I would say that this implementation is quite close to what was discussed in https://github.com/wireviz/WireViz/issues/224#issuecomment-2165326396. The only difference is that reference was implied, but implementing that is a little more tricky. Still, I think that we should clarify the outcome of #224 before merging this PR.

Please also have a look at #288, which also implements some loop handling and might cause some merge issues. What I need for my daily work is having alphanumeric pin names and pinlabels matching to work also on loops. I am currently using a workaround for this.

ex15

connectors:
  X1:
    #[...] 
    pinlabels: [GND, VCC, RX, TX, GND, VCC, GND]
    shorts:
      - SH1: [1, 5, 7]  
      - SH2: [2, 6]
    additional_components:
      - reference: SH1 # discussed in #224
        color: PK
        #[...] 
        
      - reference: SH2
        color: RD
        #[...] 

  X2:
    #[...] 
    pinlabels: [GND, VCC, RX, TX, GND, VCC, GND]
    shorts:
      - SH1: [1, 5, 7] # same designator as above... 
      - SH2: [2, 6]   # does this imply the same attributes? 

EDIT: Cross-referring to https://github.com/wireviz/WireViz/issues/224#issuecomment-2170070821 for additional details.

[tobiasfalk]

@martinrieder I think that I have resolved some of your complaints, see replies ToDo:

• [x] Syntax description
• [x] Comments/Descriptions for Ex15&16
• [x] Add tutorial

[martinrieder]

• [ ] ex15 lacks the detailed part description (mpn, etc.) in the table below the connector.
• [ ] ex16 shows loops named shortPartA/B/C due to copy & paste from ex15.
• [ ] ex16 loops cannot be destinguished by color. Could you try adding a label with the loop reference to the wires/edges?

@tobiasfalk not sure if you noticed, but PR #381 implements labels on loops. It results from https://github.com/wireviz/WireViz/issues/286#issuecomment-2094309143

Work-around to improve the #286 use case.

You might want to rename the title of this PR to highlight that it also changes the loop handling.

[tobiasfalk]

• [ ] ex15 lacks the detailed part description (mpn, etc.) in the table below the connector.

Yes since ex 15 has mini_bom enable(default) ex16 has it disabled(again)

[tobiasfalk]

* [ ]  ex16 loops cannot be destinguished by color. Could you try adding a label with the loop reference to the wires/edges?

@tobiasfalk not sure if you noticed, but PR #381 implements labels on loops. It results from #286 (comment)

Work-around to improve the #286 use case.

You might want to rename the title of this PR to highlight that it also changes the loop handling.

Ok, I will add the same fix.

Just adding lables will make it ugly, maybe some text in the connector table?

[martinrieder]

Just adding lables will make it ugly, maybe some text in the connector table?

Yes, I was thinking the same. You would also need to name the color, similar to how it is done for wires. For the colorblind it seems impossible to recognize the loops otherwise.

What about choosing a connector side for loops?

[tobiasfalk]

@martinrieder I have the Idea to add additional_cable to the connector and add references like with AddComp. Would also "solve" your complaint about the unit/qty attribute.

[martinrieder]

@tobiasfalk please explain your reasoning... The way I understand this, it could be solved by #376, which also allows defining a connector side for loops. It would not be displayed in the additional components table then.

I would call the two approaches:

• explicit loops with additional_components as handled by this PR, based on
  • #48
  • #286
  • #350
• implicit loops defined through separate cable (like #376)

[tobiasfalk]

@martinrieder my reasoning behind it was to group it with the same type of wire/cabel in the overall bom. But this can also be added later.

[tobiasfalk]

If the base is OK, I will add a tutorial and then wait for #251 to then move/reimplement this. Since this will create a bunch of conflicts.

[tobiasfalk]

@martinrieder About the Problems with the Black Circle, I really do have no Idea to have a fix for all systems, since fonts often have rendering problems. I asked for help in the GraphViz Forum: https://forum.graphviz.org/t/way-of-drawing-a-black-circle-inside-a-table-field/2273

I thought about that maybe replacing it with an X but then the centering Problem of SVG would be more prominent.

[martinrieder]

@tobiasfalk how does the × multiplication sign (×) perform instead of the letter X? It is part of ISO/IEC 8859-1 that can be explicitly defined through the charset attribute.

[tobiasfalk]

You will have the same Problem as with X

[tobiasfalk]

Also, it is kinda small: PNG:

SVG:

[martinrieder]

@tobiasfalk I finally got around to test your PR on my dev machine. It fails to run gvpr due to a path issue or missing environment variable:

Error: gvwrite_no_z problem 57
gvpr: Could not find file "pin2pin.gvpr" in GVPRPATH

You may need to use an absolute path for calling this script. I tried to set the environment variable to point to the right path and also moved pin2pin.gvpr` into the same folder, but it fails to run.

[tobiasfalk]

@tobiasfalk I finally got around to test your PR on my dev machine. It fails to run gvpr due to a path issue or missing environment variable:

Error: gvwrite_no_z problem 57
gvpr: Could not find file "pin2pin.gvpr" in GVPRPATH

You may need to use an absolute path for calling this script. I tried to set the environment variable to point to the right path and also moved pin2pin.gvpr` into the same folder, but it fails to run.

Will look in to it

[martinrieder]

@tobiasfalk I fixed it by adding the line

os.environ['GVPRPATH'] = str(Path(__file__).parent)

[tobiasfalk]

@martinrieder to where exactly?

[martinrieder]

Just before the call to gvpr in the if branch with find_executable in harness.py.

[tobiasfalk]

@martinrieder could you test it again?