Hi,
I'm wondering how to set up my auto-wire labeling system/equation so that my wires in my schematics are labeled in the appropriate avionics standard? On a quick look, it doesn't seem like there are enough user-customizable fields to assign into the equation that will "fill out" the information I need on the wire...
Thanks!
Ok, thanks for sharing that. I'm disappointed that there doesn't seem to be any way to edit the wire equation. I wonder if it's worth putting in a feature request to Solidworks for? Seems like we (avionics guys) can't be the only ones needing the auto-labeling to actually work/be customizable for our own needs...
You can edit the wire naming equation, but you can't edit the variables available to populate it. It's frustrating because all it is is a SQL query, and in a parts list report, they've given you every field in the entire project and you wind up ignoring most of them, and in the same breath, they've left out many of the critical fields you'd like to have for wire naming.
There are also some database structure oddities that complicate things, for example, a wire style can have a gauge, but an equipotential can also have a gauge, and it's possible for those to be different on the same physical wire. Never made any sense to me. You'll also notice that cable core id's can be different from the wire id underneath it.
Lots of gotcha's to be aware of when developing your reports and deciding which variables to use when driving equations.
HI Michael,
Its issues like this which can only make one question whether this is a professional product or not. As you have indicated, its possible to have conflicting wire gauge (for instance) between the wire as defined using the equipotential method, and that subsequently defined by the cable chosen for this wire. Its hard to understand why the design rule checker would ignore this possibility. It could of course lead to a potentially dangerous under-rated cable for the application, unless one takes care to manually check correspondance on every wire. But then - is'nt SWE supposed to improve productivity?
Rob
In Solidworks' defense, I will say that the deficiencies in the out-of-the-box solution are far exceeded by the benefits of using a database-oriented tool. Until we began evaluating replacements, our company used Visio or Powerpoint for system block diagram definition, and then AutoCAD for wire diagrams. This results in a tremendous amount of duplicated (and often conflicting) data, manual checking of every possible detail, inconsistency in documentation style and appearance from one engineer to the next.... the list goes on.
SWE is in it's infancy compared to other Solidworks products, and it comes from a relatively industry-specific tool, Elecworks. Naturally, there are going to be many blanks to fill in when addressing other industries that may deal with different types of equipment and wiring practices. In spite of that, I believe it will continue development in very capable hands to become a real contender in the field, especially for the price.
So, with that said, I think it's important to understand the issues it has now, and then make a firm set of rules about which variables to track, and which to discard with the reporting tool, and then develop practices for populating those variables that everyone in the group knows and adheres to. So if SWE is tracking two separate wire gauges, pick just one and make sure that's always the one you report.
I, too, think SWE needs some pretty serious additional features/capabilities in order to truly work. But it is a good start, especially for such a young product, and I'm holding onto hope that Solidworks will continue to enhance and improve SWE.
Solidworks truly owns the aviation industry when it comes to 3D modeling, so I'm hopeful they will leverage this strength and make some much needed feature improvements to SWE as related to aviation.
It's been awhile since I tried this, so I'm a bit foggy on the details, but here's what I think I remember:
The closest I got to making this happen was with a wire label symbol. We organize our wire diagrams to be system-centric by book, so the symbol included a user data attribute driven from the book properties.
Then I think I set up the wire styles to use the equipotential wire numbering scheme, so that all wires on the same equipotential would have the same numerical value. This is where passing and hyper-passing became really important.
So when you are numbering by equipotential, I can't remember if i found it as an attribute in the symbol editor... i think so. You're looking for one that refers to the equipotential segment. This would start with "A" and then increase on that equipotential for each wire segment.
Next part was the wire gauge attribute
Can't remember what I did for the suffix.
The most frustrating part was the lack of ability to concatenate and uniformly format all these separate pieces of data, so in order to prevent overruning text, I had to accept some gaps. The wire ID's looked a little like this:
1PWR001A 8 N
One thing that I think it's important to be aware of: As of 2014 SP2, SWE does not consider cable cores and wires together for uniqueness. So assuming you print your wire ids on the jackets of both wire and cable, it is completely possible that you would have a cable and a wire with the same ID.
Finally when we decided to ditch wire styles all together and use cables exclusively, the wire label approach no longer worked, which left us with manual wire/cable identification.