Improving additional component display, BOM item numbers #224
Comments
|
@formatc1702 wrote:
Dito. I was going to argue that the
I would say that the most consistent implementation is this:
Using the YAML lists (arrays) for referencing designators would align the syntax between
As stated above, I would at least rename
I would like to discuss an implementation that would also work for cables. Keep in mind that there are two common use cases:
The latter might cause confusion because wire count is an alternative multiplication factor, aa suggested in #222. qty_multiplier: populatedPlease also check the following issues related to this: |
Local DesignatorsI suggest keeping:
However, I suggest we add a local designator suffix for each In addition, all items in the When adding The short designators suggested in #350 (comment) should then also be unique within the same local scope I suggest above, so such short items could be automatically included among the Update: As an alternative to the latter, we could let the user specify details of loops/shorts entries as ordinary X1:
loops:
L1: [3, 11]
L2: [6, 12]
internal_shorts:
Sh1: [1,5,7]
Sh2: [2,8,10]
additional_components:
Sh1:
color: PK
mpn: 42A5Z42
type: 3 pin Short ov er 5 pins, name of the part
L2:
color: GR
qty: 10
unit: mm
type: Wire, 24 AWG
|
|
@kvid |
|
@tobiasfalk wrote:
I agree to that. 😄
I'm not sure I interprete this part correctly. Do you mean "and therefore always need to specify more attributes than only color and gauge"? If so, then I agree in most cases, but I've also seen very simple use cases where the diagram only is used to show the electrical connections, and has no needs for more details than perhaps different colors for readability.
What "list with all the wires" do you mean? Is it the global BOM? If so, then I agree in most cases, except in very simple use cases, like what I describe above, where a BOM is not needed at all. Is it the list of wires in a bundle? If so, then I wonder how such a bundle should be shown in relation to the connector having the loops? Do you mean a bundle node close to the connector with the loops drawn between these two nodes? If so, then I'm worried it will most often look a bit ugly because Do you mean the wire list of a bundle embedded into the connector node, e.g. just below the pin list, and loops at both sides of the connector to connect the pins to each end of the wire entry in such a wire list? If so, then it might work out well, except I'm a bit worried about readability when the number of loops increases. |
|
@kvid |
|
Also the color can either be only for the purpose of differentiation bur could also be used for defining the color of the wire isolation |
|
@kvid wrote:
Going by the Graphviz dot language specification, the ID could contain any character when it is a quoted string. The exception is:
Therefore, I suggest to put the auto-assigned numbering into brackets, which would also closely resemble the balloon numbers discussed above: EDIT: Adapting the example above, it should be possible to allow some flexibility: X1:
loops:
- L1: [3, 11] # simple loop, no additional components
- L2: [6, 12] # referenced below
internal_shorts:
# Sh1: [1,5,7] # entirely moved below, no reference
- Sh2: [2,8,10]
- # unnamed list item, auto-generated X1<1>
[3,9,11]
additional_components:
- Sh1: # named list item (added "-")
internal_shorts: [1,5,7]
color: PK
mpn: 42A5Z42
type: 3 pin Short over 5 pins
- Sh1.Sh2 # copy some attributes from above?
- L2: # named reference for "L2: [6, 12]" above
color: GR
qty: 10 # should there be an alias "length:" ???
unit: mm
type: Wire, 24 AWG
- # unnamed list item (auto-assign to X1<2>)
loops: [7, 14] # implies that it is not an "internal_short"
color: BKNote that todays's syntax has these items listed as an array (with dashes!). We should keep it this way to support the auto-generated numbering in a defined order, even if the list contains some named designators. |
|
Why not just add one ore multiple shorts or loops to a additional component, and I we should not put the pin definition in to the additional component but keep it separate. Also for shorts and loops wit wire/cable I think somthing like |
|
@tobiasfalk wrote:
Also possible, but please add some internal_shorts:
- Sh1: [1,5,7]
- Sh2: [2,8,10]
additional_components:
- [Sh1, Sh2]
color: PK
mpn: 42A5Z42
type: 3 pin Short over 5 pinsEDIT: I think that a discussion about implementing loops or shorts in a specific way is out of scope for this issue. Please try too keep it generic about Daniel @formatc1702, please provide an update on your thoughts from the original issue description. |
|
@tobiasfalk wrote:
Yes, that is normal existing behavior. I called it "BOM de-duplication" in my last comment. To obtain a match between a wire in "description" of a bundle wire = Wire, type, gauge, color That means if "type, subtype" of an additional component == "Wire, type, gauge" of a connector, then they match and they will be de-duplicated if also all remaining properties are equal. In my example above, I used @tobiasfalk wrote:
Yes, I don't see any conflict between this and my suggestions above. |
|
@tobiasfalk and @martinrieder - All your YAML input suggestions contain syntax errors. This is an example of an online YAML parser where you can test your syntax: https://codebeautify.org/yaml-parser-online Each Why do you want a list of local designators for an entry? If you want some entries to be a copy of another entry, you can use inheritance. Please explain your motivation for suggesting these strange non-YAML syntax entries, and we might find alternatives that are allowed as YAML input. |
|
Sorry, I have put the |
|
Be aware that https://www.yamllint.com/ seems to use YAML v1.2 which is different from v1.1 used by WireViz. |
This past the test, the idea behind it is to not have to type the same thing multiple times |
Thanks. I could not find that info directly on the website. This is another reason for #223 and #348. I prefer the original idea with ballooned numbers, so I strongly recommend using lists (arrays) to make that possible. @kvid your proposal in #224 (comment) was thereby simply missing the dashes. They are also present in the current WireViz syntax. You are welcome to discuss the specifics of YAML 1.1 vs. 1.2 in the other issues. |
|
@kvid wrote:
I agree with you that the proposed syntax is a bit strange from the standards perspective, although I would argue that it could be realized in perfectly valid YAML syntax. Thanks for pointing out inheritance. The point is that you might define multiple shorts or loops with dedicated additional components, similar to how you would do with pins. There might be connectors that contain different types of contacts and it would be great to have an option for listing their crimps. The latter was recently requested in #372 by @ElPi23. I made a proposal to use a connectors:
X1:
pinlabels: [GND, VCC, RX, TX, GND, VCC, GND]
shorts: # see #369
- SH1: [1, 5, 7]
- SH2: [2, 6]
additional_components:
- reference: [SH1, SH2]
color: PK
- reference: [GND, VCC] # pinlabels not unique
type: crimp1
- reference: [3, 4] # pin names are unique
type: crimp2@kvid Would this be closer to the YAML syntax that you expect? |
Oh, no, that's a misinterpretation. The restrictions you quoted were for HTML-like strings, which have to be surrounded by graph G {
// In other words, both of these are invalid graphviz:
X1<1> [color=red]; // Creates 2 nodes, "X1" and "1"
X1<1> [color=red]; // Syntax error
// But this is perfectly legal:
"X1<1>" [color=green shape=box];
// (And this, which is the form that note was describing):
<X1<1>> [color=blue shape=box];
}So, if you're using quoted strings, there's no restriction on including If you're using HTML-like strings for node names... well, I wouldn't recommend that, because it gets ugly fast. (And wouldn't really solve the problem, because you'd end up with a user who wanted to use a reserved character like Better, I think, to just surround the user-provided content with some characters — in all uses — to ensure uniqueness. For example:
Even if the user creates a global ID But unless you're modifying the user's content in some way when storing it, there's always a chance they can enter a string that, unmodified, collides with IDs generated from other unmodified names. |
I have been using WireViz at work quite a bit (work being the main reason I haven't had time to contribute to the project 😕) and I have noticed the treatment of "main" components and additional components is not as consistent as it maybe should be.
Note: The following thoughts might partially contradict previous opinions and decisions... this is what happens when theory meets practice.
Take the following sample file:
Source
Issues (easily solvable)
show_part_numbersparameter could optionally hide the subtype (unused in this example),part number and manufacturer+mpn fields if desired, to match the current information content of the additional components list.#4etc.), where as main components (connectors and cables) do not. It should be either both, or none.show_bom_item_numbersthat then applies to both?#symbol and the brackets in the additional component list visually jarring.. perhaps there is a more elegant solutionThey appear to go at least up to ㊿.
This is similar to "balloons" used in mechanical technical drawings
Other thoughts (discussion required)
E.g. someone might want connectors numbered from 1, cables numbered from 50, use letters for crimps, etc...
E.g. A
X1is item1, then the crimp could be1a, the housing1b.Both these ideas complicate the idea of using custom unicode characters for a nicer rendering of the item number. Please see this as food for thought, perhaps we can come up with a nice solution.
Here's a mockup of what
X1from the example above might look like using rounded table borders to create "balloons" for BOM item numbers. The issue of different widths for the BOM balloons is there, but not a total dealbreakerGraphviz Source
The same component, rendered with the proposed
show_part_numbersattribute set tofalse, to keep the graphics simple, and allowing cross-referencing with the BOM:And the same component, with
show_bom_item_numbersset tofalse, to contain all the information within the graphic and eliminate the need for BOM export, and BOM item number balloons:The only thing getting lost in this case would be any
additional_bom_itemsdefinde outside of connectors and cables, but I see that as a separate issue.Personally, I would vote for having
show_bom_item_numbers = Falseandshow_part_numbers = Trueby default. This way, no information is lost when using only the graphics output, where as BOM cross-referencing is left as an "advanced" feature.The text was updated successfully, but these errors were encountered: