Simple Harness fails to parse when referencing past Pin 1

[WillNotAccept]

I'm defining a simple harness and it fails to parse with

• ValueError: 2 is not in list

I've connectors on either end of a cable that are field wireable connectors (and thus screw connections) and so need ferrules. So I folled the documentation and examples to create connector, ferrules, cable ferrules, connector and got the above error.

I've reduced it to the example below and I don't think I have the syntax wrong given that I can replace the pin numbers with 1 and it works other than, of course, the connections being wrong. I also cannot use pin names without getting an error. could be getting input syntax wrong, it does seem unreasonably sensitive to whitespace, but it's not obvious to me that I am.

If the pin is replaced with 1 it parses but not any pin number larger

connectors:
  J1:
    type: 82-100266-00
#    image: 
#        src: 82-100266-00.png
#        width: 100
    pincount: 5
    pinlabels: [Shield, 24V, 0V, CAN_H, CAN_L]
    pins: [1, 2, 3, 4, 5]

  J2:
    type: 82-200052-00
#    image: 
#        src: 82-200052-00.png
#        width: 100
    pincount: 5
    pinlabels: [Shield, 24V, 0V, CAN_H, CAN_L]
    pins: [1, 2, 3, 4, 5]

  F1:
    subtype: 82-100123-00
#    image: 
#        src: 82-100123-00.png
#        width: 100
    type: Crimp ferrule
    style: simple
    color: RD

  F2:
    subtype: 82-100122-00
#    image: 
#        src: 82-100122-00.png
#        width: 100
    type: Crimp ferrule
    style: simple
    color: GY

  F3:
    subtype: 82-100121-00
#    image: 
#        src: 82-100121-00.png
#        width: 100
    type: Crimp ferrule
    style: simple
    color: BU

  F4:
    subtype: 82-100120-00
#    image: 
#        src: 82-100120-00.png
#        width: 100
    type: Crimp ferrule
    style: simple
    color: WH

  F5:
    subtype: 82-100124-00
#    image: 
#        src: 82-100124-00.png
#        width: 100
    type: Crimp ferrule
    style: simple
    color: GY

cables:
  W1:
    type: 82-100048-00
    length: 0.6096
    shield: true
    colors: [RD, BK, WH, BU]

connections:
  -
    - J1: [2] 
    - <--
    - F1.
    - W1: [RD]
    - F1.
    - -->
    - J2: [2] # Works if 1

#  -
#    - J1: [1]
#    - <--
#    - F5.
#    - W1: [s]
#    - F5.
#    - -->
#    - J1.[1] #2: [1]
#  -
#    - J1: [3]
#    - <--
#    - F2. 
#    - W1: [BK]
#    - F2. 
#    - -->
#    - K2: [1]
#  -
#    - J1: [4]
#    - <--
#    - F4.
#    - W1: [WH]
#    - F4.
#    - -->
#    - K2: [1]
#  -
#    - J1: [5]
#    - <--
#    - F3.
#    - W1: [BU]
#    - F3.
#    - -->
#    - K2: [1]

[WillNotAccept]

And FWIW, the user name is because it was difficult to find a name GitHub would accept, not a jab at anything/one

[kvid]

@WillNotAccept - Thank you for reporting this error message, but please always provide all information about your set of versions as described in contributing guidelines and how you installed WireViz and dependencies. Otherwise, it might be hard to help you when nobody knows how to recreate the error you report.

However, the error message looks similar to #355, so this might be a duplicate issue. Please try my fix in PR #358 and report the outcome.

Update: After testing your YAML input with my PR #358 (see below), I'm convinced this issue is caused by the same bug as #355, and hence is a duplicate issue.

[WillNotAccept]

I'll take a look. I wasn't expecting a programming task to create a wire harness. It took me a while to realize that's what you were suggesting

[kvid]

@WillNotAccept wrote:

I'll take a look. I wasn't expecting a programming task to create a wire harness. It took me a while to realize that's what you were suggesting

I'm sorry for not explaining what I mean by "try my fix in PR #358". You don't need to program anything. To try the code in a PR, this procedure can be used, except you can skip the 9th command (deleting the downloaded files), and replace the 4th command (git clone) with any of the download variants below to get the correct branch:

1. Click the link to the PR - Fix bugs in mate processing #358 in this case.
2. Below the title, you find the text: {author} wants to merge {n} commit(s) into {target branch} from {source branch}.
3. Click the {source branch} - fix355 in this case.
4. Click the green Code button.
5. If you have git installed, then you can clone using any of the 3 alternative methods, e.g. git clone https://github.com/wireviz/WireViz --branch=fix355 to download the code.
6. If you are not familiar with git, you can instead download a ZIP with all the code, and unpack it in your selected folder.

[kvid]

I just tried processing the YAML input provided above with WireViz from my fix355 branch without errors. As expected, I got the following warning and the diagram output shown below:

Warning: The following components are not referenced in any connection set:
F2, F3, F4, F5

I also tried including all connections that was commented out (and added a dummy K2 to avoid errors) and got this output:

I suspect the - J1.[1] #2: [1] originally was - J2: [1] and that K2 was J2 pins 3, 4, and 5, and then changed to track down this bug. If I change this back to what I suspect was the original, I get this output:

If the last diagram above was your original goal, then I it's possible to combine all your single-wire connections into a much more compact multi-wire connection with an almost identical result (the drawing order of splines might differ, though):

connections:
  -
    - J1: [1-5] 
    - <--
    - [F5., F1., F2., F4., F3.]
    - W1: [s, 1-4]
    - [F5., F1., F2., F4., F3.]
    - -->
    - J2: [1-5]

Another possible simplification: The connector attribute pincount: 5 is redundant when providing 5 entries in pins and/or pinlabels.

[WillNotAccept]

Or simply just replace the change file which is what I did (and would consider programming in the sense that I'm changing the source). That did fix the issue, although not the referencing by pin name which must be something different elsewhere but amounts to syntactic sugar and is easily just ignored by using pin numbers

[WillNotAccept]

Yep, I had separated it into separate groups just trying to narrow down the problem. That was purely an artifact of the troubleshooting

[kvid]

I suggest you create a separate issue for "the referencing by pin name" you still experience, and please include a simple example YAML input that triggers the problem, and provide your versions as described in the contributing guidelines.