PDM, data card variable for "copied from" data

[bnemec]

Many of models, parts or assemblies, are copied from an existing then edited. We would like to have a record of what file another file came from. In theory this would be simple with data card variable, just set it to %sfilenamewe% in the CopyTree user/group settings. But much of the time the new file is a product of SaveAs from Solidworks. So I could use the workflow transitions to help me out maybe. We have an automatic state between the only "new file" state named Initiated and WIP. If I had two variables, one with the filename without extension and one for copied from I could simply copy the Filename (which would still be the filename from the source file if there's no default value set in the data card control) to Copied From variable. Great. How do I populate the Filename variable? Well with default value on data card control. Erm, no, then it would be changed before I have a chance to get the source file name by set variable action in that automatic transition from Initiated to WIP. So I set it in that automatic workflow transition right after copying it to the CopiedFrom variable. That souns good, but what if the file is renamed? How do I keep the "filename" variable updated with the actual file name? Only thing I can think of is set the Filename variable in several of the transitions in the workflow to keep it updated incase the file gets renamed.

This seems like a long way around a very simple task. Does anyone have a simple way of doing this that doesn't depend on a bunch of pieces in a bunch of places?

Thanks.

[jcapriotti]

I think you're on the right path, san resorting to the API. You will have to store the "Filename" on the data card, meaning you need to set your legacy data, maybe with "Modify\Update values in files".

Once set, when you copy the file, the new file's data card will have the original filename. Don't set defaults, you want it to keep the original file's name.

Then add a "Copied from" variable, set its default to clear.

Have an "Initiated" state in your workflow for new files with the transition.

image.png (6.92 KiB) Viewed 1994 times

Create a "Set Variable" action, first to copy the filename, then to set the filename. I set "Overwrite Latest Version" so I wouldn't create another version but if you have other variables with SolidWorks mapping, you can't use it.

Like you said, it your users can rename files, you may need to set filename at other parts of the workflow. Maybe not all of them but certainly "Release". We don't allow renaming once it leaves WIP except by an admin to correct a mistake.

Not really what you asked for....I think I just confirmed the path you were already on.

[bnemec]

@jcapriotti I appreciate the over view even if I was already on the path. There are a lot of pieces to miss, mistake or get out of place so the review from a more experienced set of eyes is helpful.

[jcapriotti]

It was an interesting problem, and I enjoy trying to figure this stuff out. The thing is, you can Copy Tree, Save as, and Copy/Paste. I couldn't see a way to hold the filename in the latter two, it had to already be there. I wonder if the API has calls to intercept the "Save as" or "copy/paste".

[the_h4mmer]

Branching (I know it's not the same and doesn't fix the user side of things), let's you set variables on the branched file from the source file using the Branch User Settings. Plus you would have the 'associated branches' option to trace back to the source, especially when it comes to a branch of a branch of a branch...

Speaking of which, the workflow for copying while setting the source filename that @jcapriotti outlined would start to lose ties to the source when a copy of a copy is made, right? I mean you could trace the copy back to the original copy, which would then reference the original file copied, but that seems like it could get a bit cumbersome.

[JSculley]

It was an interesting problem, and I enjoy trying to figure this stuff out. The thing is, you can Copy Tree, Save as, and Copy/Paste. I couldn't see a way to hold the filename in the latter two, it had to already be there. I wonder if the API has calls to intercept the "Save as" or "copy/paste".

You can hook into these events:

EdmCmd_PreAdd 11 = One or more files are about to be added to the file vault
EdmCmd_PreCopy 19 = One or more files are about to be copied to a new folder

You missed one other way files are copied/added: 'Make Independent/Virtual', followed by 'Save Part in External File'.

[jcapriotti]

Speaking of which, the workflow for copying while setting the source filename that @jcapriotti outlined would start to lose ties to the source when a copy of a copy is made, right? I mean you could trace the copy back to the original copy, which would then reference the original file copied, but that seems like it could get a bit cumbersome.

The workflow should take care of that as long as the user is instructed to move the file from "Initiated" to "WIP" after they add files. That way it sets the new copy's filename variable. You could make it automatic transition with some conditions like "No files with %copy% in the filename". There are still use cases where it could slip through.

[bnemec]

You can hook into these events:

EdmCmd_PreAdd 11 = One or more files are about to be added to the file vault
EdmCmd_PreCopy 19 = One or more files are about to be copied to a new folder

You missed one other way files are copied/added: 'Make Independent/Virtual', followed by 'Save Part in External File'.

Oh man, creating new files... Solidworks has more ways to create new files that PDM doesn't handle than the other way around. Speaking of getting serial number for file name or using the PDM Templates (which we do not) there are mirroring, splitting, and a couple others I have forgotten. We actually had to make a FAQ for renaming CAD files with serial number, using PDM's Move Tree, after SW saves them through one of the whiz-bang fast modeling features that people think they have to use.

Thing is with creating the new files from scratch isn't something we're trying to catch in this case though. Creating a new file from scratch/template doesn't have a "copied from" to record. What we want is when and existing model (sldasm or sldprt) is copied, as a work flow to create a new part number from an existing part number with just a few changes, we record the file is was copied from. We actually encourage the process of copying sldprt files, instead of starting from template, when the parts are going to be very similar so that they can be interchanged down the road so assembly mates and drawing annotations are more likely so survive. Well, it was in Solid Edge any way, hopefully it's still valid in SW.

[bnemec]

Branching (I know it's not the same and doesn't fix the user side of things), let's you set variables on the branched file from the source file using the Branch User Settings. Plus you would have the 'associated branches' option to trace back to the source, especially when it comes to a branch of a branch of a branch...

Speaking of which, the workflow for copying while setting the source filename that @jcapriotti outlined would start to lose ties to the source when a copy of a copy is made, right? I mean you could trace the copy back to the original copy, which would then reference the original file copied, but that seems like it could get a bit cumbersome.

I think Jason's response covers this, at least as far as what I can foresee being a concern.

As for the copy of copy of copy of issue you mentioned. Very good point as this is very normal for us. I call it Daisy Chaining references and I actually prefer it over every child pointing back to the root ancestor because of the way our parts live and evolve. The chain is not linear, there are branches in it, more of a tree structure than a list. Back before we started looking at SW and PDM, after I had set up indexing of all the CAD file references on the network share, I was also doing some conceptual modeling to index and provide GUI of the "copied from" reference tree. It was going alright in spite of the files not being a in vaulted system. Anyway, my point is reading these daisy chained, copied from, values is quite easy for API to do using a little recursion. The long term concept is adding a tab to Vault View to display copied from and copied to (like a contains or where used tree) to show this copied from data. But it's pointless if we cannot get good data stored to populated the GUI.

[the_h4mmer]

I think Jason's response covers this, at least as far as what I can foresee being a concern.

As for the copy of copy of copy of issue you mentioned. Very good point as this is very normal for us. I call it Daisy Chaining references and I actually prefer it over every child pointing back to the root ancestor because of the way our parts live and evolve. The chain is not linear, there are branches in it, more of a tree structure than a list. Back before we started looking at SW and PDM, after I had set up indexing of all the CAD file references on the network share, I was also doing some conceptual modeling to index and provide GUI of the "copied from" reference tree. It was going alright in spite of the files not being a in vaulted system. Anyway, my point is reading these daisy chained, copied from, values is quite easy for API to do using a little recursion. The long term concept is adding a tab to Vault View to display copied from and copied to (like a contains or where used tree) to show this copied from data. But it's pointless if we cannot get good data stored to populated the GUI.

I remember you mentioning the recursion API work previously, you're definitely more into that side of things than me, but I hope to catch up some day! For me, I think having a full picture of the lineage would be extremely helpful, so if you do end up making something like that, I for one, would be quite interested to see it in action (and have a look under the hood if permissible).

[bnemec]

I remember you mentioning the recursion API work previously, you're definitely more into that side of things than me, but I hope to catch up some day! For me, I think having a full picture of the lineage would be extremely helpful, so if you do end up making something like that, I for one, would be quite interested to see it in action (and have a look under the hood if permissible).

I know just enough to be dangerous. My skills lack experience and practical guidance, I only have what I've picked up from the API corners of SE and SW forums and another kind soul that helped me tremendously on the PDM API. Thankfully, my CS/SE Instructors back in school were dedicated enough to drive some fundamental concepts into my skull so there is some level of general integrity in what I've written. Some days I wish I could go back and just audit some of their lectures again and thank them.

[bnemec]

It stinks that there's no option for %filenamewe% in set variable transition action. I know there's a file name without extension in other place(s), maybe branch/copytree user settings? Some consistency would be so much nicer.

Am I missing something? I don't see an option for filename without extension. It's not a show stopper, but certainly don't need the extension in this case, it's obvious it was copied from the same type.

Had to go look. It's the copy tree/branch user/group settings that offers %filenamewe% notice they snuck the 's' in there for source I assume. Confession, due to some ID10T error in the workflow transition actions we might have a few files that have the filename value set to "%filenamewe%"

[AlexB]

It stinks that there's no option for %filenamewe% in set variable transition action. I know there's a file name without extension in other place(s), maybe branch/copytree user settings? Some consistency would be so much nicer.

Am I missing something? I don't see an option for filename without extension. It's not a show stopper, but certainly don't need the extension in this case, it's obvious it was copied from the same type.

Out of the box, I don't know of a way to do this...

I managed to do this with the attached Dispatch script if you import the action into your Dispatch add-in (assuming you use it) then you can hook it to run before or after your target workflow state.

Edit: If you have additional conditions for the file, then those can be added to the dispatch script as well. You can also modify the check-in to overwrite existing versions as well if you prefer. It's currently set not to.

[jcapriotti]

It stinks that there's no option for %filenamewe% in set variable transition action. I know there's a file name without extension in other place(s), maybe branch/copytree user settings? Some consistency would be so much nicer.

image.png

They finally added it in 2022....not that that helps.

[bnemec]

They finally added it in 2022....not that that helps.

image.png

Actually, this is good to know, thank you. Good to know they're making these little improvements.