Only add one PN to a datacard?

[Brian-M]

I'm talking about the PDM-P serial number generator. It adds a PN (part number aka Serial Number) to every existing configuration. And then if you add a configuration - it adds another PN! In most cases we'd prefer one PN per file.
Thanks!

[jcapriotti]

In your datacard, make sure your number field is set to "Updates all configurations"

If you need to have a serial number for "some" configurations it gets more complicated and you have to use the "Exclude configurations" option and really standardize your configuration naming schema.

[Brian-M]

Aw dang. Thanks very much Jason, but I was hoping you wouldn't say that. I was hoping for way to only put it on the @ tab. If I use updates-all, then it'd be difficult to use the occasional multiple PN file. ...I may try something like an add-on part number tool https://equivaq.com/product/serial-number-rename-tool

[Brian-M]

Hey, we may get some use from the Exclude Configurations idea!
https://help.solidworks.com/2021/englis ... Redirect=1
We could start adding a standard string to config names to prevent it from generating serial numbers. {non} or mono or something.
Better than what's going on now.
Thanks!

[jcapriotti]

Yeah, you'll need a strict naming standard. Things like "*FLAT*" so it doesn't add a number to flat configurations. Same goes for some other functions that utilize configurations like speedpaks and alternate position views, etc.

[bnemec]

Are you using some file naming convention other than serial number or part number?
Curious for the reasons you didn't use serial number for file name then set part number to filename without extension?

[Brian-M]

Thanks for mentioning that approach, made me reconsider some things. This is a an existing PDM setup, wherein they made some weird decisions, and now I'm the new admin trying to figure out improvements.

The current filenames are often just descriptions (hoping to change this). They don't use the @ tab (may change), and they want the option to be able to put SN on various configurations. As far as I can tell the weak SN tool in PDM-P isn't set up for that (amazing it can't be run on state change; it has an exclude, but how about an include? etc.), and I'll probably need an add-in to get everything we want.

I'd like to filename with SN, but doubt that would satisfy enough of the requirements. It would work for most files, but as often happens with PDM, it's the exceptions that cause 80% of the PDM admin time. In this case, how would we grab another SN if we wanted two in one file?

https://www.goengineer.com/blog/solidwo ... up-and-use

[bnemec]

Thanks for mentioning that approach, made me reconsider some things. This is a an existing PDM setup, wherein they made some weird decisions, and now I'm the new admin trying to figure out improvements.

The current filenames are often just descriptions (hoping to change this). They don't use the @ tab (may change), and they want the option to be able to put SN on various configurations. As far as I can tell the weak SN tool in PDM-P isn't set up for that (amazing it can't be run on state change; it has an exclude, but how about an include? etc.), and I'll probably need an add-in to get everything we want.

I'd like to filename with SN, but doubt that would satisfy enough of the requirements. It would work for most files, but as often happens with PDM, it's the exceptions that cause 80% of the PDM admin time. In this case, how would we grab another SN if we wanted two in one file?

https://www.goengineer.com/blog/solidwo ... up-and-use

I understand that, even though I'm first PDM Admin here I still gripe about weird things the previous guy did. Hind sight is much better than foresight devoid of experience.

I still have mixed feelings about the @ tab, tempting to just hide it for all the SW files. As far as I understand it's only helpful for non-SW file types.

I don't have any experience applying serial numbers to data card variables, we only have one SN generator set up in PDM and it is only used for file names.

I don't know how to put multiple serial numbers in one file for various part numbers in configs. I don't know that you would want to. We went down the path of using configurations for different part numbers but ran into enough problems that aborted that. Had several files configured like that with several hundred configs/part numbers in each; we are still working on getting those configs saved out as single files. (there's no quick way to save a config out of a part file, need to save a copy then delete all the other configs... time consuming.)
In the little bit of PDM experience I have, it sounds like one part number per file is a good "rule" in PDM. But I'm sure there's exception cases where it could work. Our use case is not an exception, so the rule here is no more than one part number per file. PDM is a >file< management tool, part number in PDM is just a variable, nothing special. I'm not saying it cannot be done, it can be; we tried for a while and it just became less than ideal method.

There's still some hang-ups with using serial numbers for file names. The PDM add-in only hooks the Save file dialog, so all the other nifty methods of saving new files from SW cannot get a SN and you will need to use the Move Tree command to rename those files with serial numbers.

Oh, and don't expect to get 100% usage of serial numbers if using them for file names through the PDM add-in, there will be skips.

[Brian-M]

Thanks for the notes on practical experience bnemec. Good reminder on the Move Tree tip, I saw that mentioned somewhere. I think my next tactic will be to push for dash numbers on configs. One PDM serial number per file, and manual addition of dash numbers when needed.
I imagine you use only SN for filename? If we want filenames to also include a description does it need to be manually renamed?

In defense of the @ tab, it's nice to have the option to apply default values (description, material, etc), which will be used if config specific values don't override. At another job we used mainly the @ tab, rarely was any text metadata on a config. With one PN per file I'd expect that is the general best practice - but I don't know if there is consensus.
Toolbox parts would be an example where the good stuff is config specific.

[bnemec]

Thanks for the notes on practical experience bnemec. Good reminder on the Move Tree tip, I saw that mentioned somewhere. I think my next tactic will be to push for dash numbers on configs. One PDM serial number per file, and manual addition of dash numbers when needed.
I imagine you use only SN for filename? If we want filenames to also include a description does it need to be manually renamed?

In defense of the @ tab, it's nice to have the option to apply default values (description, material, etc), which will be used if config specific values don't override. At another job we used mainly the @ tab, rarely was any text metadata on a config. With one PN per file I'd expect that is the general best practice - but I don't know if there is consensus.
Toolbox parts would be an example where the good stuff is config specific.

Don't go by just what I say, I'm just sharing what I've seen in our little use case. Please get several voices before making a change.

We do use serial number for file name, for better or worse. People are still tempted to put trash in the file name for various "special" cases; I threaten to delete (but not destroy) files that have trash in file name. Have followed through on that a couple times after a bit of investigation. Note, users cannot delete file once it has been through the Released state.

We still use the "Default" config in any part with configs for various stuff. The Default config is the "vanilla" version of the part and is the one that would be used in assemblies and on main sheet of print. So our files have an inherent default that we use instead of @.

Funny you bring up toolbox. I was avoiding the "Standard parts" or "off the shelf" or "hardware" keywords when I was typing about configured parts, but since you opened that can... We do not have "off the shelf" (OTS) hardware, every nut, screw, washer and spacer has a part number and is maintained (revised). We decided pretty quick that toolbox would not work for us but we were lured into using configs for hardware. It didn't work out, like I mentioned, we're still saving those configs out to unique files. Hopefully your situation is different and you don't track hardware in ERP/MES and don't revise hardware like we do.

[DanPihlaja]

... (there's no quick way to save a config out of a part file, need to save a copy then delete all the other configs... time consuming.)...

Quick side note:
The tool #Task will do this for you. It used to be free, but now comes with a cost.

https://centralinnovation.com/solidwork ... s/task-v2/

[bnemec]

Quick side note:
The tool #Task will do this for you. It used to be free, but now comes with a cost.

https://centralinnovation.com/solidwork ... s/task-v2/

Thats interesting, thanks for sharing. I don't think I saw that one when I was searching though. I decided to write our own, the files needed to be saved into PDM with a specific filename from the config name and then checked in.

[Brian-M]

Also Hawkridge has a "Configuration Exploder": https://hawkwareapps.com/hawkwaretools.html

[berg_lauritz]

I understand that, even though I'm first PDM Admin here I still gripe about weird things the previous guy did. Hind sight is much better than foresight devoid of experience.

I still have mixed feelings about the @ tab, tempting to just hide it for all the SW files. As far as I understand it's only helpful for non-SW file types.

You would hide the @ tab? So do you actually use the custom property tab within Solidworks or do you always update the datacard through PDM? Do you have an Add in?

[bnemec]

You would hide the @ tab? So do you actually use the custom property tab within Solidworks or do you always update the datacard through PDM? Do you have an Add in?

I meant the @ tab on data card in PDM. It's difficult to explain to users the diff between @ and Default data card tabs when most of the files have only one config and I still don't think I understand all the differences in PDM about the @ tab myself.
Most of our data card variables are set to update all configs, we left description so that users could edit description of the configs that show an assembly in various positions; top, mid, bottom for example. That became so confusing to the users because half didn't notice if they had the @ tab or a config tab selected or even that it mattered, then even more confusing is what is shown in that column in the contains and where used tabs; it was usually different than what was shown in the middle pane. Also, when the description was not set to update all configs half of the files would have either the @ or Default blank because they didn't know they had to set it in both.
We do have a few "library" parts that are in a different directory that get a different data card and they have less variables with "update all configs" set.

Data card only. Editing properties from the custom property tab in Solidworks is not allowed here. I cannot imagine how that would ever work if you have PDM variables mapped to those custom properties. We had a couple clowns that thought they were clever and would edit from the custom properties dialog. One guy thought he could "Fix" the revision by editing the custom properties, I had to make his life a bit difficult for a bit to get him to quit it. Users are like electricity in an RLC circuit. They will follow the pathS of least resistance. Tend to continue following a path once it's established so much so that removing that path is likely to cause sparks. And, they have the capacity to do much work or great harm.

Only add-in right now is PDM task add-in that runs dxfs and pdfs with tasks set up to be run when files are approved.

[Brian-M]

Data card only. Editing properties from the custom property tab in SolidWorks is not allowed here. I cannot imagine how that would ever work if you have PDM variables mapped to those custom properties.

It can work fine to edit Custom Properties in SWx if you have users that understand the system (and probably a drawing review process). But I agree it's safer to encourage metadata changes from the data card - the PDM setup has more control over changes. It depends what you are doing of course... e.g. you may have a drop down list on the card (watermark, or finish), within SolidWorks someone can go off script, and enter whatever they want.

[berg_lauritz]

I meant the @ tab on data card in PDM. It's difficult to explain to users the diff between @ and Default data card tabs when most of the files have only one config and I still don't think I understand all the differences in PDM about the @ tab myself.
Most of our data card variables are set to update all configs, we left description so that users could edit description of the configs that show an assembly in various positions; top, mid, bottom for example. That became so confusing to the users because half didn't notice if they had the @ tab or a config tab selected or even that it mattered, then even more confusing is what is shown in that column in the contains and where used tabs; it was usually different than what was shown in the middle pane. Also, when the description was not set to update all configs half of the files would have either the @ or Default blank because they didn't know they had to set it in both.
We do have a few "library" parts that are in a different directory that get a different data card and they have less variables with "update all configs" set.

Data card only. Editing properties from the custom property tab in Solidworks is not allowed here. I cannot imagine how that would ever work if you have PDM variables mapped to those custom properties. We had a couple clowns that thought they were clever and would edit from the custom properties dialog. One guy thought he could "Fix" the revision by editing the custom properties, I had to make his life a bit difficult for a bit to get him to quit it. Users are like electricity in an RLC circuit. They will follow the pathS of least resistance. Tend to continue following a path once it's established so much so that removing that path is likely to cause sparks. And, they have the capacity to do much work or great harm.

Only add-in right now is PDM task add-in that runs dxfs and pdfs with tasks set up to be run when files are approved.

With regards to the original problem - how would you i.e. delete properties on multiple parts? Or change them?
You can not really do a multi-select & delete i.e. the part#, can you?
Can you regenerate a batch of part# on the datacard?

[bnemec]

With regards to the original problem - how would you i.e. delete properties on multiple parts? Or change them?
You can not really do a multi-select & delete i.e. the part#, can you?
Can you regenerate a batch of part# on the datacard?

I might not be following correctly, but are you talking about delete/change properties on multiple parts in one file? We don't do that, one part number per file for us; we struggled in many places having more than one part number per file in PDM.

That said, and keep in mind our users are not to be editing custom properties in Solidworks, data card controls can be set to "Update all Configurations" in the Data Card Editor. That is how we keep the description, part number, etc the same across @ tab and configs or sheets on drawings. Not a multi-select but is more like a select all affect.

I'm sorry, I don't know what you mean by "regenerate a batch of part# on the data card" If you're asking about getting serial numbers applied to data card variables that have the Default Value set to "Serial number" I think the only way to get new SN for those is in the Copy Tree or Move Tree dialog. Or using the API and IEdmSerNoGen7 object https://help.solidworks.com/2019/englis ... csharp.htm

[Brian-M]

I have some good news for you guys! I was considering a variety of complex workarounds, or an add-in, and then one of my coworkers pointed out you can right click on the data card SN field, and select Generate next serial number to make a new one. File must be checked-out.

The trick to make this really usable the way I was hoping... a single asterisk. On the card editor field where you are using the SN generator, put * into the "Excluded Configurations" box, and it doesn't use any SN by default! Works even for non-cad files that don't have configs.

Now you can easily generate a SN where you want it. Can be config specific, or not.

...Next I'll see if I can use a macro to start the filename with the SN variable. The reverse of the method I've seen described.

[jcapriotti]

I have some good news for you guys! I was considering a variety of complex workarounds, or an add-in, and then one of my coworkers pointed out you can right click on the data card SN field, and select Generate next serial number to make a new one. File must be checked-out.

The trick to make this really usable the way I was hoping... a single asterisk. On the card editor field where you are using the SN generator, put * into the "Excluded Configurations" box, and it doesn't use any SN by default! Works even for non-cad files that don't have configs.

Now you can easily generate a SN where you want it. Can be config specific, or not.

...Next I'll see if I can use a macro to start the filename with the SN variable. The reverse of the method I've seen described.

Nice, I wonder when they snuck that one in.

[Brian-M]

Apparently it's been around since at least 2010. https://help.solidworks.com/2010/Englis ... umber.html

FYI For some reason the exclude asterisk didn't work for drawings - for a test SN generator there, so each sheet added would generate another SN.
But I'm so happy to have this very flexible solution for all other file types and data cards.