Numeric Revision Numbers but get letter in data card every once in a while

[bnemec]

Our Revision number is set up as numeric, we should never see a letter in the revision variable. Yet since we started with SW and PDM we occasionally see a letter in the revision field on the data card, but just the @ tab, the "Sheet" tabs show correctly. Which is bogus because that field on data card is set read only, and updates all configurations.

I've been blaming Solidworks for this rather than PDM. Oh, and we (for better or worse) decided to let PDM automatically manage the rev table on the drawing.

We have a couple of dead cases at the VAR for this, mostly closed because I don't take the time to get all the vault backups and sql reports and backups and what all else they ask for. As I'm typing this I'm getting deja-vu as I'm pretty sure I started a thread on it in the past; I looked for it here but couldn't find it. Anyway this gets reported every once in a great while and I've been trying to find a commonality, some repeating "thing" associated with it. It has happened twice this week, fortunately one of the users had not checked the file in yet, so now I'm 99.8% certain it's nothing to do with PDM. Also, he mentioned that he had added a row to the revision table manually. The second guy that reported it confirms that he manually removed a row from the rev table. So now I have a bit of a common thread.

Anyone else ever see this?

Thanks.

[jcapriotti]

It' more than likely the revision table. In your SolidWorks settings, you have this settings for drawings that defines the custom property for revision:

And this for revision table:

If you manually add a row to the rev table, it will push the next revision letter to the "Revision" custom property. "Custom" is mapped to the @ tab in PDM so it's probably overwriting it.

[bnemec]

It' more than likely the revision table. In your SolidWorks settings, you have this settings for drawings that defines the custom property for revision:

image.png

And this for revision table:

image.png

If you manually add a row to the rev table, it will push the next revision letter to the "Revision" custom property. "Custom" is mapped to the @ tab in PDM so it's probably overwriting it.

I think you're hot on it's trail. Custom Property name:

And Variable mapping:

Grayed out saying "Revision is driven from SOLIDWORKS PDM"

[jcapriotti]

Does it turn off the ability to add revision from the table?

[bnemec]

Does it turn off the ability to add revision from the table?

yep. my PC puts the '~' character in the table revision column but does not change custom property. I'll check with others.

[jcapriotti]

yep. my PC puts the '~' character in the table revision column but does not change custom property. I'll check with others.
image.png

Maybe a bug there......or maybe someone had their PDM add-in turned off and was able to "Revise" the table?

[bnemec]

Maybe a bug there......or maybe someone had their PDM add-in turned off and was able to "Revise" the table?

It's messy. feels like another room in the house of cards.

If the file is not saved into the vault yet (new file) but I'm very much connected to PDM, then I can Add Revision over and over and get A, B, C etc. If the file has been checked in then I can only Add Revision once and it gives me the '~' character (which I think is somewhere in PDM but I don't recall where right now.)
Edit: found where the '~' is comming from:

[jcapriotti]

@bnemec I see, so if the file isn't saved in the vault yet, it allows it. I guess I could see that, it doesn't yet know if you plan to work in the vault yet so locking that option may not be desirable for some I suppose.

On a somewhat related note, we have a default value for the revision on newly added files. The reason being that users will copy files from various locations, in or out of the vault, and they may have a revision value. Since we need PDM to start at "A" for first release, we set that revision with a default and check it with a transition condition.

[bnemec]

@bnemec I see, so if the file isn't saved in the vault yet, it allows it. I guess I could see that, it doesn't yet know if you plan to work in the vault yet so locking that option may not be desirable for some I suppose.

On a somewhat related note, we have a default value for the revision on newly added files. The reason being that users will copy files from various locations, in or out of the vault, and they may have a revision value. Since we need PDM to start at "A" for first release, we set that revision with a default and check it with a transition condition.

Yep, we do the same/similar. Default values in the data card, new files start in "Initiated state" with automatic transition to WIP that sets things again or other actions that can be done. Which leads to why we see this so rarely. Those measures have no effect when a new file or another file is SaveAs an existing filename in the vault. So as far as PDM is concerned it's not a new file, just a new version.

[jcapriotti]

Wouldn't the "save as" file enter the workflow and trigger those defaults?

[bnemec]

Wouldn't the "save as" file enter the workflow and trigger those defaults?

I don't think so when Saving As an existing file name that is checked out by the user. I'm pretty sure it just puts a new version on the stack when it gets checked in.

[jcapriotti]

"Save as" should create an entirely new file in the system in which it creates a data card with defaults, if you have the defaults set to overwrite.

A "save as" over the existing file isn't any different than a save. Just a new version on check either way. But since it was already a PDM registered file, the revision should already be set and it should lock the rev table.

[bnemec]

"Save as" should create an entirely new file in the system in which it creates a data card with defaults, if you have the defaults set to overwrite.

A "save as" over the existing file isn't any different than a save. Just a new version on check either way. But since it was already a PDM registered file, the revision should already be set and it should lock the rev table.

Yes.

There's nothing stopping a user from creating a new file and saving it with the same name as another file in the vault (assuming they have that file checked out) which does happen sometimes to get the latest doc properties from the template. Although I have not yet confirmed that's what happened here concerning getting a letter vs the '~' character.

Also the revision variable is linked to the files' custom properties, if the Revision property is changed (either by user or by SW) while the file is checked out, when the file is checked back in the revision on data card is updated from custom file properties per variable mappings, just like any other variable right?

In the data card editor "read only" and "updates all configurations" only applies to updates made through the data card, there are many other things (such as custom property mappings) that can change the variable values.

[jcapriotti]

Yes.

There's nothing stopping a user from creating a new file and saving it with the same name as another file in the vault (assuming they have that file checked out) which does happen sometimes to get the latest doc properties from the template. Although I have not yet confirmed that's what happened here concerning getting a letter vs the '~' character.

Yes, you could overwrite the checked out file with another file doing a save as. Not a recommended process but we've done it on occasion.

Also the revision variable is linked to the files' custom properties, if the Revision property is changed (either by user or by SW) while the file is checked out, when the file is checked back in the revision on data card is updated from custom file properties per variable mappings, just like any other variable right?

In the data card editor "read only" and "updates all configurations" only applies to updates made through the data card, there are many other things (such as custom property mappings) that can change the variable values.

Yes, the custom properties in the file will update the data card when checked in. So a user could manually edit "Revision" to be anything and potential mess up the data card property. No way to prevent that until SolidWorks provides a lock mechanism on them. Until then you can maybe enforce it with workflow conditions to some extent.

[bnemec]

Yes, you could overwrite the checked out file with another file doing a save as. Not a recommended process but we've done it on occasion.



Yes, the custom properties in the file will update the data card when checked in. So a user could manually edit "Revision" to be anything and potential mess up the data card property. No way to prevent that until SolidWorks provides a lock mechanism on them. Until then you can maybe enforce it with workflow conditions to some extent.

But it's not the users changing the custom property. Well, not directly. It's something in Solidworks setting the revision for the @ configuration to a letter. The other configs/sheets still have proper revision number.

As you pointed out earlier, it's likely the "Add Revision" in the rev table that's causing this behavior.

Also, as you clarified earlier, once the drawing is added to the vault the rev table is "locked" in that adding a revision [row] to the table will should always get the '~' rather than letters.

I'm trying to confirm whether the user saved a new file over an existing file when a drawing gets the revision on @ tab set to a letter. From what I've seen that's not always what's going on. If I could compare the file GUID from an older version to the latest version. That would confirm if it was a new file saved over existing file or not.

With Solid Edge files I could open the files with any compound file reader and get the file GUID, Solidworks files will not open as a compound storage structure so I cannot use that method to get the files GUID. I haven't seen a way to find that info on Solidworks files. If I confirm that it's always a new file then it's because users are trying to get the rev table caught up before ever saving the file into the vault. If the older version and newer version of the drawing have same file GUID but newer version has revision set to a letter then there's something else wrong. right?

[jcapriotti]

We don't use Rev tables but if you insert a new rev table in a drawing already in PDM at say revision "M", will the rev table start with "M" when you add a rev?

We've always relied on PDM for revision history. The drawing title block now only contains information for the ECO it was released on. Since we create a PDF of each drawing revision as a separate PDM record, when we search for PDFs of a particular part number, we have columns that show the ECO information so it's a revision table of sorts.

[bnemec]

Still watching this and have a few pop up now and then. We have confirmed and replicated that the process of deleting and adding a row in the revision table (automated through PDM) will cause SW to set the revision custom property to the next letter. The letter scheme is zero based, in that if the file is at rev 00 and the rev table is edited the custom property is set to A. If the file is released at rev 06 and transitioned to WIP then the rev table is manually edited for whatever reason. A row is deleted and new one added the letter will be H which corresponds to the next rev of 7.

It is repeatable for a file that exhibits the behavior, but not all files will do it. I believe at some point along the bumpy beginning phases of our venture into PDM and Solidworks there was a time where some setting caused files created during that time to have this problem. We cannot find any new files that have this problem so we're fairly certain it was a problem at one time that was corrected before this symptom showed up or before we correlated it. I don't know that there is a fix aside from redoing the affected drawing from scratch when one is found. The work around is in the rare case that the rev table has rows added or removed manually the Admin must fix the revision.

It would be nice if we had sheet specific custom property tab (like the configuration specific custom property in model files) so that we could just fix the custom property from the property editor as the revision control is read only on the data card and that setting is not per user. Would also be super cool if admins could edit read only controls on the data card but that's another story. So other than using API to set variables, the only way to fix the revision variable on drawings is to use Set Revision which stamps that version with a rev which isn't exactly what we want, but it works.

[berg_lauritz]

We don't use Rev tables but if you insert a new rev table in a drawing already in PDM at say revision "M", will the rev table start with "M" when you add a rev?

We've always relied on PDM for revision history. The drawing title block now only contains information for the ECO it was released on. Since we create a PDF of each drawing revision as a separate PDM record, when we search for PDFs of a particular part number, we have columns that show the ECO information so it's a revision table of sorts.

Sorry to kind of hijack here:
So how do you keep track of what's changed? Just through history in PDM/ECN/ECO? Nothing else?


H

Still watching this and have a few pop up now and then. We have confirmed and replicated that the process of deleting and adding a row in the revision table (automated through PDM) will cause SW to set the revision custom property to the next letter. The letter scheme is zero based, in that if the file is at rev 00 and the rev table is edited the custom property is set to A. If the file is released at rev 06 and transitioned to WIP then the rev table is manually edited for whatever reason. A row is deleted and new one added the letter will be H which corresponds to the next rev of 7.

How did you add a leading 0 there? We will be changing our revision system this year & a leading 0 gave us problems.

Can you delete the rev table, copy all the contents, re-insert & just add a new line to fix the problem? You can also re-set the document properties to your gusto at the same time.
We i.e. do that to fix our PDM copy tree'd/branched drawings that way...

[bnemec]

How did you add a leading 0 there? We will be changing our revision system this year & a leading 0 gave us problems.

Can you delete the rev table, copy all the contents, re-insert & just add a new line to fix the problem? You can also re-set the document properties to your gusto at the same time.
We i.e. do that to fix our PDM copy tree'd/branched drawings that way...

Once the rev number is copied to the data card variable (using transition action set variable = %nextrevision% ) it's just dumb text, nothing special. From there everything uses the data card variable or the mapped custom file property.

The "Revision Number Component Properties" in the Admin Tool is where we set the rev number format.

As for deleing the rev table and re-insert rev table, I suppose maybe. Thing is the user doesn't usually notice that SW has changed the custom file property Revision to a letter until they've checked it in, only twice now did someone contact me before checking the file in, that's how I tracked down to SW and not PDM doing it. Unless there's history comment of the file getting a letter rev in the past there's no way of knowing that it will happen when editing the rev table. Setting Rev isn't that hard, we've done it A LOT over the past couple years.

As for manually setting custom properties:
1) I may have received a grievance from chastising some for going in and manually editing the revising custom property when they thought they could do that to "fix" the revision. Also had other cases of people making more wrongs while fixing things in the custom file properties. So I've mostly tried to strongly discourage users from touching custom properties as they are mapped to/from PDM and most of the users just screw them up even worse.
2) cannot change custom properties for the sheets in SW Drawing files, only the @ tab. Most of the controls on the data card is set to update all configurations but that only applies when user is updating variables on the data card, every other mechanism that edits data card variables can do whatever it likes, including manually editing custom file properties. Then the users will see contradicting data depending on which tab they are looking at in the data card view or if a config is selected in the contains or where used tabs. I think having tabs for sheet specific custom properties was added functionality recently or maybe on the TTL?

[jcapriotti]

So how do you keep track of what's changed? Just through history in PDM/ECN/ECO? Nothing else?

The ECO has a folder and supporting documents in PDM including a redlined markup of the drawing changes. The drawing only has the current revision along with the ECO number, date changed, drafter and engineer who changed it.

[bnemec]

I'm ~95% certain this is caused by deleting the top row in the rev notes table. We also see it mess up rev number on the data card (@tab only) from numeric to numeric it just wasn't as obvious as numeric to alphabetic; we've never used alphabetic revs. Why some do alphabetic I believe is due to the time period the drawing was created, we had a bumpy start with a secondary migration, and many goes at getting templates set up.

There's something about how the top (or most recent) row in the rev note table seems to be bidirectionally linked to the custom properties and the PDM Solidworks Add-in is a one-way, one-shot connection from PDM transition action to the cells in rev table. I don't know that I even want to try to understand all the underlying mechanisms of how it works. At the end of the day, I've just told people to avoid deleting or inserting row to the top of the rev table on the drawing and if they MUST do that, they'll just need to contact the PDM admin to fix the rev.