Show Branched Part.

[MJuric]

Recently branched parts where brought up here and already I've had the opportunity to use them a few times.

My question is whether there is a way to show the "Branched" version of a part in an assembly without merging the changed part. I know I can just drop it into the assy or replace the existing one but that can get messy. I could also "Branch" the assembly and replace the part I suppose but it would be nice to just be able to show the branched part, like a different configuration or something.

[Uncle_Hairball]

Please define 'branched part'.

[Craig Schultz]

Do a copy tree on that part/drawing and replace. That should start you over with a clean part.

[bnemec]

Please define 'branched part'.

Its a PDM thing

https://help.solidworks.com/2019/englis ... branch.htm

Branch is much like CopyTree except PDM keeps track of the relation between the source and branched file. Both methods create a new file.

As for swapping out the source file in an assembly for a version of the branched file it would be like replacing with any other file. Although I don't think I would do that, what we've done (if we want this) is to just add the branched file to the assembly in addition to the source file. Optionally hide the source file. As with anything PDM you can only have one version of a file on your computer at one time so use the PDM add-in to get a specific version you want to see.

edit: we were told that the branched files should not live on forever, one of the branches should be merged and then they can be deleted or archived.

[MJuric]

Its a PDM thing

https://help.solidworks.com/2019/englis ... branch.htm

Branch is much like CopyTree except PDM keeps track of the relation between the source and branched file. Both methods create a new file.

As for swapping out the source file in an assembly for a version of the branched file it would be like replacing with any other file. Although I don't think I would do that, what we've done (if we want this) is to just add the branched file to the assembly in addition to the source file. Optionally hide the source file. As with anything PDM you can only have one version of a file on your computer at one time so use the PDM add-in to get a specific version you want to see.

edit: we were told that the branched files should not live on forever, one of the branches should be merged and then they can be deleted or archived.

So I talked to my VAR on this and the answer is "No, but that would be a great enhancement request."

I think this should be added to the missing 5% thread that no longer really exists.

While "In Process EC's" is a good use for this the biggest area I can see this being used is in design iterations. However in order to see how a part looks, works, fits in an assembly...well you have to be able to see it in the assembly.

So you branch a part and you can redesign it and say "Yeah I think that is what I want", but the only way to see it in the assembly is to either place it in there, replace the part in the assembly that you branched from, or merge the part. The latter essentially makes your original part go away so you would have to get an older version of it to bring back the old one.

How I see this as it should be...in my opinion, is you branch a part. You then go back to the assembly and you can select the branched part similar to a configuration of that part.

By doing this you could branch a whole bunch of parts and mix and match and then when you find what works you merge those...done.

[MJuric]

Please define 'branched part'.

If you have PDM and have this feature installed you can "Branch Part" and it creates a copy of that part. Yu can then change that part and it will have no effect on the original part. If you like the changes you can then merge the part back to the original.

[bnemec]

So I talked to my VAR on this and the answer is "No, but that would be a great enhancement request."

I think this should be added to the missing 5% thread that no longer really exists.

While "In Process EC's" is a good use for this the biggest area I can see this being used is in design iterations. However in order to see how a part looks, works, fits in an assembly...well you have to be able to see it in the assembly.

So you branch a part and you can redesign it and say "Yeah I think that is what I want", but the only way to see it in the assembly is to either place it in there, replace the part in the assembly that you branched from, or merge the part. The latter essentially makes your original part go away so you would have to get an older version of it to bring back the old one.

How I see this as it should be...in my opinion, is you branch a part. You then go back to the assembly and you can select the branched part similar to a configuration of that part.

By doing this you could branch a whole bunch of parts and mix and match and then when you find what works you merge those...done.

yes exactly. Consider branching the assembly as well? Just for the sake of comparison. Then delete the branched assembly when done and merge the desired branch of the part once the change is approved.

Often times there are several parts that interact with each other, maybe even parts in different weldments (.sldasm, not .sldprt) so then maybe even branch the assembly where the weldments are joined. Notice the Branch command has the contains tree in it, so select the top assembly that you want to test on for the branch command. First thing to do in the branch dialog is right click, uncheck all. Then you check the parts you want to change and the assemblies you want to test them in. This way you can save your work from day to day without needing to check out the where used of the parts you intend to change.
Just a thought.

[MJuric]

yes exactly. Consider branching the assembly as well? Just for the sake of comparison. Then delete the branched assembly when done and merge the desired branch of the part once the change is approved.

Often times there are several parts that interact with each other, maybe even parts in different weldments (.sldasm, not .sldprt) so then maybe even branch the assembly where the weldments are joined. Notice the Branch command has the contains tree in it, so select the top assembly that you want to test on for the branch command. First thing to do in the branch dialog is right click, uncheck all. Then you check the parts you want to change and the assemblies you want to test them in. This way you can save your work from day to day without needing to check out the where used of the parts you intend to change.
Just a thought.

Pretty much every day I run into some product where I say "Did the people who designed this actually use it?". This is one of those cases. Either the people who designed this aspect of SW only worked on individual parts...or they rarely used it. I used it twice. First time I just branched something to see how it worked, played with the part and went "Wow! That's cool". Second time I actually branched a part I wanted to modify from an assembly. Branched the part, changed it and said "Ok, what's that look like in the assembly?....wait, what!? There's no way to look at it changed in the assembly?"

I'm going out on a limb here to say that probably most people working with professional level CAD systems aren't working only on parts, they are working on assemblies. So once again we have a feature that is "Cool" but not really effectively useable for the majority of it's users.

[SPerman]

I find myself daily thinking: "Either people who write software have no idea what they are doing, or I'm so old that I don't understand modern interfaces."

[bnemec]

I find myself daily thinking: "Either people who write software have no idea what they are doing, or I'm so old that I don't understand modern interfaces."

If you use MS Visual Studio you will realize that programmers (in the most general sense) can be quit good. See Visual Studio is written by programmers for programmers, so they know exactly how it should function. It works very well IMO, the settings are intuitive, any new user can find settings because the layout is logical and sensible. The GUI flows well and default layout is good. It is every bit as complicated as a CAD software on the level of Solid Edge, Works or Inventor. I'm 99.9% certain that modern programmers of any of the CAD systems that became successful enough to be bought by corps and turned into cash cows are very good, they just do their job as their told to do it by a person who answers to a person who answers... ...to a board of investors who don't know CAD from Paint or a Forum from Facebook.

I digress.

Want to see branched parts in an assembly that should stay in the released state? Just branch the assembly too, play in that one then delete it when done.

[jcapriotti]

Yeah, it helps if the programmer is also a user of the software. It's nice that my programmer was a CAD designer in SolidWorks in the past and knows our systems.

Branch/Merge is definitely unfinished and a missed opportunity. We were already doing something similar before it existed but more manual to do and track. Engineers would copy (per our standard) files and prefix them with an ECO number or Project number and do their design iterations. Then when done, the doc control group could copy them and overwrite the master files on the ECO. If we were staying on PDM, I'd probably have my guy code an add-in to automate this more to handle the copy operation and workflows transitions (I already have some ideas on it but Windchill beckons).

[MJuric]

Want to see branched parts in an assembly that should stay in the released state? Just branch the assembly too, play in that one then delete it when done.

I'm not sure how this would work. In order to now change the original part wouldn't I have to branch the assembly AND all the parts I want to work with in that assembly? I didn't try it so this may not be true but my thoughts were that I could branch the assembly but that assembly would be populated with the original parts would it not? If I branched a part in that assembly it would be the same as branching the original part. If I merged it at that point does it not merge the original?

If I branched the entire assembly and all the parts I want to play with isn't the only way to get that part back to the released assembly is to merge the entire assembly? That doesn't seem like something I would like to do for a massive assembly.

What am I missing here?

[bnemec]

I'm not sure how this would work. In order to now change the original part wouldn't I have to branch the assembly AND all the parts I want to work with in that assembly?

No no, only branch the files you want to edit. if you branch from a top down it will update the parent assemblies to ref the branched files for you. If you want to see the original then you'll need to manually add them back into the branched assembly. Any parts that were not branched will use the existing (assuming production released and protected from checkout) files.

I didn't try it so this may not be true but my thoughts were that I could branch the assembly but that assembly would be populated with the original parts would it not?

yes I believe that is correct, so you would also, at the same time, want to branch the parts you want to evaluate changes to.

If I branched a part in that assembly it would be the same as branching the original part. If I merged it at that point does it not merge the original?

You're loosing me a little, but the point is the branched assembly will reference the branched part and the source assembly will be left referencing the source part. I assume you want the source files left alone for now as they are in some released state and no checked out permission. If/when the changes to the part are approved then just delete the branched assembly(ies) and merge the part back into the source. Then once the original (source) assembly is updated to pull new version of the changed part you'll have your changes.

If I branched the entire assembly and all the parts I want to play with isn't the only way to get that part back to the released assembly is to merge the entire assembly? That doesn't seem like something I would like to do for a massive assembly.

When you merge the branched file back into the source it just makes a new version of that part file same as if you checked it out, made edits, saved and checked in. There's no magic. So the where used, once updated, will show what was merged.
Remember, branching a file(s) is the same as doing a copytree of the file(s) only the branch keeps a record of what they were copied from so they can be merged later.

[MJuric]

You're loosing me a little, but the point is the branched assembly will reference the branched part and the source assembly will be left referencing the source part. I assume you want the source files left alone for now as they are in some released state and no checked out permission. If/when the changes to the part are approved then just delete the branched assembly(ies) and merge the part back into the source. Then once the original (source) assembly is updated to pull new version of the changed part you'll have your changes.

I may be looking at this wrong but let me see if I can clarify.

I start with Assembly 123 that has part ABC in it that I want to mess around with.

I branch the assembly and the part so I have 123-V1 and ABC-V1.

I now want to see my changes in the assembly so I merge. Doesn't ABC-V1 merge with ABC thereby updating the original?

So the other way is this which I think Might work.

I branch 123 and ABC to 123-V1 and ABC-V1

I then branch ABC-V1 to ABC-V2 and do changes on that. What I've not tried is what happens when I merge ABC-V2 with ABC-V1. If it only merges to the -V1 level that it's is branched to then you could merge -V1 with -V2 and then merge -V1 back to the original. Is that what you're suggesting? Again I haven't tried that yet.

[bnemec]

I may be looking at this wrong but let me see if I can clarify.

I start with Assembly 123 that has part ABC in it that I want to mess around with.

I branch the assembly and the part so I have 123-V1 and ABC-V1.

I now want to see my changes in the assembly so I merge. Doesn't ABC-V1 merge with ABC thereby updating the original?

So the other way is this which I think Might work.

I branch 123 and ABC to 123-V1 and ABC-V1

I then branch ABC-V1 to ABC-V2 and do changes on that. What I've not tried is what happens when I merge ABC-V2 with ABC-V1. If it only merges to the -V1 level that it's is branched to then you could merge -V1 with -V2 and then merge -V1 back to the original. Is that what you're suggesting? Again I haven't tried that yet.

I fear I'm over complicating this. Originally you were just branching the part ABC to ABC-v1, right? But you wanted to see it in the where used assembly 123. I'm assuming 123.sldasm is in some Released state and cannot be checked out (which can be a pain with SW read only warnings and such) So I suggested branching 123 to get 123-V1.sldasm that you can either replace the original ABC with ABC-V1 or you can have them both in there. Since 123-V1.sldasm is still in WIP you can save it at the end of the day, even check it in for others to view. At this point ABC.sldprt and ABC-V1.sldprt are not different versions of one file, they are separate files. So you cannot toggle back and forth in the assembly unless you have them both in the assembly.

Then when you're done evaluating ABC-V1.sldprt you merge ABC-V1 back into ABC as a new version and delete 123-V1.asm If you want to see the changes made to ABC.sldprt in the assembly you can go open 123.sldasm and make sure that you have latest version of ABC.sldprt using the PDM Add-in. At the risk of muddying the waters, at this point the latest version of ABC.sldprt is a copy of ABC-V1.sldprt, so now you can get an older version of ABC.sldprt to see it before changes.

I hope that didn't make things worse.

[MJuric]

Iyou can either replace the original ABC with ABC-V1 or you can have them both in there.

That's the part I'm trying to get around. If you could just display ABC-V1 as a configuration of ABC then you would neither have to add or replace ABC.

While this may not be a big thing if you're dealing with a single part if you have 4-5 parts each with 2-3 "Branches" now you're either adding in 8-15 parts and turning them on and off/configurations etc or each time you want to view one part that was changed with another part that was changed you have to replace the part.

For Example, let's say you had parts A, B, C and D and had -V1, -V2 and -V3 for each part. Well If I want to see A-V1 with B-V1 and C-V1 I have to either replace three parts or put all those parts in the assembly. But now I want to see A-V1 with B-V2 and C-V2...See where I going with that?

If instead you could do branches the same way you can do configurations and just click the pull down and click -V3...super cool.

Without that however it's really nothing more than a glorified copy and replace.

[bnemec]

That's the part I'm trying to get around. If you could just display ABC-V1 as a configuration of ABC then you would neither have to add or replace ABC.

While this may not be a big thing if you're dealing with a single part if you have 4-5 parts each with 2-3 "Branches" now you're either adding in 8-15 parts and turning them on and off/configurations etc or each time you want to view one part that was changed with another part that was changed you have to replace the part.

For Example, let's say you had parts A, B, C and D and had -V1, -V2 and -V3 for each part. Well If I want to see A-V1 with B-V1 and C-V1 I have to either replace three parts or put all those parts in the assembly. But now I want to see A-V1 with B-V2 and C-V2...See where I going with that?

If instead you could do branches the same way you can do configurations and just click the pull down and click -V3...super cool.

Without that however it's really nothing more than a glorified copy and replace.

And you're correct, the "glorification" is the link between branched file and source so it can be merged. When we were first looking at it we thought we could use branch to keep record of what parts are copied from other parts. Majority of our part files are copied from an existing part then edited (customized for one customer) and saved as a new part number. Having a reference of what file was copied to make the new one would be a huge time saver years later when there may be a dozen variations of the part in several variations of the assemblies they go to. But we learned that PDM will not support that kind of use of branching.

I agree that it's another half implemented feature. I could say that the planners don't really know all the various ways customers will try to use the function so they don't finish it, but I'm pretty sure marketing wanted a new feature to put in a bulleted "What's new in ..." list and there's a limited number of hours available.

What you're asking for would be a great API project since the references are all there in PDM one could automate the process of adding new branched parts to the parent assembly(ies). The trick would be setting up the right UI. Just thinking about it for a moment I would still want the parent assemblies branched to temporary test files. So a SW add-in accessible from the assembly that would check if the current asm is a branch, if so then go to the source assembly and get a list of the components that have been branched and find all those branches. Then offer the user a tree view of those files and left them select which ones to add to the currently open assembly. Since it knows which component the branch file comes from it could position them in the assembly according to each one's source file.