NWF File - "NEW CABLE"

[sully7]

Hey everyone,

I've been working on some automation and techniques related to the Cabling environment, and while exploring these areas, I came across a few questions about Creo's native capabilities.

Most examples I've seen will define cables as independent wires. You will have "NEW WIRE_SPOOL"s and "NEW WIRE"s to define an array of wires in a harness model.

However, I know its possible to define both cable spools and cable definitions through the NWF file.

NEW CABLE_SPOOL	CABLE_SPOOL_1	3
PARAMETER UNITS	INCH
PARAMETER NUM_CONDUCTORS	3
PARAMETER THICKNESS	0.7
PARAMETER MIN_BEND_RADIUS	10
PARAMETER WIRE_GAUGE	0.0
CONDUCTOR	1
PARAMETER UNITS	INCH
PARAMETER COLOR	WHT
PARAMETER THICKNESS	0.1
PARAMETER MIN_BEND_RADIUS	2
PARAMETER WIRE_GAUGE	0.0
PARAMETER CONDUCTOR_NAME	2463
PARAMETER COND_ID	1
CONDUCTOR	2
PARAMETER UNITS	INCH
PARAMETER COLOR	BLU
PARAMETER THICKNESS	0.1
PARAMETER MIN_BEND_RADIUS	2
PARAMETER WIRE_GAUGE	0.0
PARAMETER CONDUCTOR_NAME	2475
PARAMETER COND_ID	2
CONDUCTOR 3
PARAMETER UNITS	INCH
PARAMETER COLOR	RED
PARAMETER THICKNESS	0.15
PARAMETER MIN_BEND_RADIUS	2
PARAMETER WIRE_GAUGE	0.0
PARAMETER CONDUCTOR_NAME	2451
PARAMETER COND_ID	3

With that spool definition defined, we can similarly define a cable using the following format:

NEW CABLE	CABLE_1	CABLE_1	CABLE_SPOOL_1
CONDUCTOR	1
ATTACH	CONNECTOR_1	2	CONNECTOR_2	1
CONDUCTOR	2
ATTACH	CONNECTOR_1	3	CONNECTOR_3	1
CONDUCTOR	3
ATTACH	CONNECTOR_2	2	CONNECTOR_3	2

This NWF format will import and parse into Creo appropriately, but when I go to actually autoroute the cables, it seems as though Creo cannot find the entry ports on the appropriate connectors (post-designation, of course), meaning it will not actually perform any autorouting. However, if I model the cable instead as several independent "NEW WIRE"s (aka, 3 NEW WIRE instead of 1 NEW CABLE), it finds the appropriate connector entry's as expected, and autoroutes just fine.

Has anyone had any experience using CABLES in NWF files instead of WIRES? I've attached an example NWF file here.

Thanks,

Sully

[gkoch]

If you manually route the cables with their conductors and you export the design logic to neutral, does it look the same as the neutral file would have looked, that you want to import?

[sully7]

Nope. If I manually create the cable and export it to neutral, it only shows "NEW CABLE CABLE_1"... and that's whats interesting about it. It doesn't include any connectivity information for that cable or its conductors at all.

Just to explain a little more, if I export out a cable with a single conductor, it will show

NEW CABLE CABLE_1 B

ATTACH SULLY_WG_SKEL "" SWITCH11 ""

But the second I include a 2nd or 3rd conductor, the exported definition becomes:

NEW CABLE CABLE_2 C

It seems to me like it is a functionality that was never actually finished, and so Creo knows that the cable exists, and that it has information about it (visible through spool definition etc), but for some reason it cannot actually route the connectivity for each individual conductor.

[sully7]

I did find this document, that supports that this capability SHOULD be possible:

https://support.ptc.com/appserver/cs/view/solution.jsp?n=122559&posno=1&q=NWF%20File

[BrianMartin]

Hi Sully,

I can help with this. I'm not at a place right now where I can write but I have examples of defining and autorouting with cables instead of wires. I'll get back to you about this later today. I just need some time to get back to my desk. We did a whole section on autorouting cables in Ninja Cabling 3D at this year's PTC Live.

Thanks,

Brian

[sully7]

Hi Brian,

Yes I've actually followed many of your posts and seen a few of your powerpoints/PDFs/videos so far; they have been a huge help so far!

Take your time responding - I do appreciate you reaching out.

Thanks again,

Sully

[gkoch]

Hello James,

have you been able to autoroute as desired with the help of Brian?

And - if yes - can you - or Brian - provide the essence of what solved your issue here in the thread?

I am sure others will be interested, too.

Thank you,

Gunter

[sully7]

Not yet, but I'm sure we'll figure it out soon enough . I will definitely post as soon as Brian or I figures anything out.

[BrianMartin]

Hi Sully...

I'm sorry this fell off the radar. I'm looking at this now. I believe this is a problem where autorouting individual conductors of a cable doesn't work. Try autorouting the entire cable... and I think that works correctly. From what I recall, you may have to connect the ends of the conductors manually and allow the network to route the rest of the cable back to the breakout points (where the individual conductors branch from the main trunk of the cable).

I'm pretty sure this is right but I need to check with Cassandra (Kemp), my co-presenter from the Ninja Cabling 3D presentation. She'd know this off the top of her head.

Thanks! And sorry for the delay!

-Brian

[BrianMartin · Accepted solution]

HI again (for the second time)...

There's some nuances to the cable routing. First... "breakouts" are going to cause problems. Second.. the network will keep your cable conductors bundled... but they will tend to split out into discrete conductors in areas where there is no network.

It's all a bit wonky and it's not nearly as clean as individual wires.

I think I see some issues with your NWF, though. I believe you need an extra line to make it work- plus I also believe you might have a logic error. Let's take the logic error first...

• If you're using a cable, those conductors will be bundled together as a single entity. The way your NWF reads though... each of the three conductors goes to a different connector. I've created a logical diagram of what's occuring in your NWF. See below (click for a larger image). My point here is that you wouldn't use a cable for this type of connection. You'd only want to use a cable for instances where it makes sense to have multiple conductors bundled together. In this case, it doesn't appear to (unless I am misunderstanding your application).

The second issue is more of a formatting issue with the NWF file itself. The link you provided to the PTC.com article is correct. You can autoroute from a cable definition. But I think you're missing a bit of data that's required. I think you are missing the data in the light orange box (with the red text - in the image below). Also, you do not need the Parameter Name data, but you may add it if you wish. Click the image below for a larger version.

I think if you correct the logic error and change the NWF file to incorporate that "Main Attach Statement", your cable will autoroute. Note in the example above, the only common connection that could be specified in my Main Attach Statement was the From connector "P3". On the From side, the cable attached to multiple pins so none could be specified. An empty "" was included to denote that none could be specified on the From side. On the To side, neither a common connector nor pin could be specified. This is why there are two more empty "" sets.

Still, for a cable to make sense... there has to be one common denominator. In this case, the connector P3 was a common starting point. Without this, I don't think you can get the cable to route the way you wish. I could be wrong though.

I'd start by adding a Main Attach Statement to your NWF as shown above and per the example in the PTC.com article. For your current NWF, I guess you'd use four "" empty statements because there's no connector common to all conductor attachments. I don't think this will work, but it's worth a try. Next, I'd try making all of the cables originate from one connector and have it branch to the other two. I believe this will get your cable routing properly.

There's a whole other lesson on how to use the network to keep the conductors together in a bundle or have them break out into individual, discrete conductors. That part is tricky and there aren't a lot of options. Still, I think this will get you going in the right direction.

I'm really sorry it took so long to get this to you... but I hope this gets you moving again!

Thanks,

-Brian

[sully7]

Brian,

Thanks for the detailed response!

You were right about the missing "" in the neutral files. That definitely solved one of the main problems.

The second problem that I noticed however is that each CONDUCTOR requires a "PARAMETER NAME <namehere>" in order to autoroute (it'd be nice if the Import would have failed to let me know.... but that's a different point). My NWF file was missing that, and it was included in the one showed in the image you attached. So I tested it a bit, and found that to be the main issue we were having. As a side note, the NAME does not have to match the conductor, so a you can name any wire individually anything you would like

As for the logic issue, that was also definitely an error on my part. I simply threw together a text example to try to identify the issue. However after testing it using four "" sets, it actually will still route appropriately! So I went to an even farther extreme by adding a 4th connector (aka, 4 connectors, 3 conductors), and it still autorouted successfully for me! See below (again, names changed to generic names for techincal reasons):

NEW CABLE CABLE_2 CABLE_SPOOL_1

ATTACH "" "" "" ""

CONDUCTOR 1

ATTACH CONNECTOR_1 1 CONNECTOR_21

PARAMETER NAME 1

CONDUCTOR 2

ATTACH CONNECTOR_3 2 CONNECTOR_4 2

PARAMETER NAME WIRE_1

CONDUCTOR 3

ATTACH CONNECTOR_3 3 CONNECTOR_4 1

PARAMETER NAME 3

Therefore, I think its almost better to ALWAYS specify the ATTACH "" "" "" "" for any cable definition, because it will ensure the autoroute (if that's your goal, obviously. If you're worried about faulty NWF definition, then you may want to include the common element to be sure it routes as its supposed to).

It'd be great if PTC supplied all of these rules, a breakdown of all the requirements for the NWF, and all of the standard cabling parameters somewhere... or did I just miss it?

As you mentioned in your post, routing cables is definitely more of a pain than routing individual wires... but I think we may be able to use it in our application pretty nicely. I need to do some testing to see if/how this may work when routing to a network (as you also mentioned), but at least now the first half of my issue has been fixed.

Thanks so much for your help!

[BrianMartin]

Hi James...

Because I haven't ever tried autorouting a cable without the Parameter Name statement, I didn't know it was required. That's a great piece of information to capture. As you correctly pointed out, there is no single place to find all of this data. This was the point behind creating Ninja Cabling in the first place. It's also what I was referring to in the thread about "Secret Cabling Techniques". I mean, it's not intended to be a big secret but because of the obvious and glaring lack of documentation for the last 20 years, it just is a big secret.

Just this basic thread about autorouting cables has yielded some great information to capture. The aforementioned "parameter name <xxx>" issue is just one. Adding to that, you've found it's possible to route cable conductors to a non-common set of connectors. Even though your diagram unintentionally split up the connectors- you were still able to route by using the double "" for all fields in the main attachment statement. This is another thing I'd never thought to try! Your suggestion of always using ATTACH "" "" "" "" seems solid. I'd say we need to keep testing but I'm going to use this in my future cable autoroutes!

For documentation, I started creating a very detailed document on the NWF file format and the various options, requirements, and limitations it has. I had visions of putting down all of my NWF knowledge and that which has been published in other locations into one single document for posterity. As I started this, I found that no matter how I tried to add visual elements and explain the NWF format, it was still tough to explain.

The guide was starting to get lengthy and I wasn't even done with the section on spools. I've attached the first draft I was working on (it's been posted here before). One thing I've learned about lengthy documents from working where I work... is that people don't read them. I can spend 100 hours on a beautiful, concise, detailed document full easy-to-understand graphics hoping to provide all the information people will ever need- and yet they'll still call or email me for the answer rather than read.

Instead, I decided to build the intelligence of that document into a software program. That way people didn't have to learn any of the various options. All they'd need to do is select options from a drop-down menu, tick some check boxes, or enter text in a dialog box and the file would be created for them in the correct format. Even better, once that software is created, there's no reason it can't export NWF files and XML files, too. There are some options available via XML file that are not available in an NWF. I reasoned it might be better to have one tool that could leverage both formats.

So then- what are your thoughts on a document versus software? Do you still see value in a document given the knowledge that we're probably going to have to create it ourselves (as a Community)? I'd really doubt that PTC is going to invest resources in that effort. When people realize they can do all the fancy autorouting and auto-designation of connectors without the schematic capture package and without specialized training- at least some people will want to try it! Therefore, it's probably a bit counterproductive for PTC to expend too much effort advertising that fact.

If you think there's still value in finishing the attached document, let's talk about it more.

Thanks!

-Brian

[sully7]

Brian,

I definitely agree that although it is nice to put together solid documentation, most users rarely want to flip through a large document, when they could simply get the "cliffnotes" version of it from someone else, or have it automated through software. Software also comes in handy because as long as it is up-to-date with the latest standard, it means that users would not need to thumb through to find what they need to change in their NWF files, the software can just handle the change-in-requirements automatically.

That being said, I think it is definitely useful to have some master archive of all this knowledge somewhere, especially if PTC doesn't provide one themselves. I would be glad to help you work on the attached document if you want! I'll send you a message with my personal contact info.

Thanks again for helping work through this issue!

~ Sully

[BrianMartin]

:Snicker:

It's kind of funny, I sent you a response to your personal email that says the same thing as your last post! Sorry I didn't read this before I responded. I think we're on the same page though.

I have another person who's also volunteered to jump in with the documentation. I think we can probably product a quality master document and use that as a roadmap for the software. I'm anxious to post a screenshot of the software but I know it's prudent not to until it's ready to go.

No sense giving every other company out there a chance to beat me to the punch, right?

Thanks!

-Brian

[gcangane]

Hello Brian,

I've searched almost all PTC Community looking for the complete documentation about NWF files attached in earlier posts as draft version. Is it finished? Is it available somewhere?

Any help would be greatly appreciated.

Thanks in advance.

[MikkoHinkkanen]

Try this as an full documentation.

https://support.ptc.com/appserver/cs/view/solution.jsp?n=122559

[ptc-5185843]

Are there any NWF details for a sheath or bundle spool and how would you integrate it with different routes?

[MikkoHinkkanen]

According to my lmited knowlidge, the NWF is provided as is for serveral Creo Parametric releases. No new develpoment. Create Product Idea and I´ll vote for it.