WireViz icon indicating copy to clipboard operation
WireViz copied to clipboard

Simple Harness fails to parse when referencing past Pin 1

Open WillNotAccept opened this issue 1 year ago • 8 comments

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 avatar May 22 '24 03:05 WillNotAccept

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

WillNotAccept avatar May 22 '24 03:05 WillNotAccept

@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.

kvid avatar May 22 '24 04:05 kvid

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

WillNotAccept avatar May 22 '24 13:05 WillNotAccept

@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 - #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 avatar May 22 '24 15:05 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

issue359 I also tried including all connections that was commented out (and added a dummy K2 to avoid errors) and got this output: issue359_ 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: issue359__ 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.

kvid avatar May 22 '24 17:05 kvid

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 avatar May 22 '24 20:05 WillNotAccept

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

WillNotAccept avatar May 22 '24 20:05 WillNotAccept

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.

kvid avatar May 23 '24 21:05 kvid