In our PDM (sw 2023) we are using quite some datacards and I am trying to consolidate their use.
I did not make this vault, so I want to clean up some legacy mess.
I redesigned the datacards, fixed lot of misconfigurations and now I am at the point of considering their deployment into the vault.
The first thing I am thinking about is card naming and versioning.
At the moment the card has a very long and explicative name, and often there are many copy of the same card since the vault root folder was not used and every subfolder has a copy of the generic part and assy cards repeated over and over.
The first approach I am considering is to eliminate all the copies as possible and consolidate them into the root folder, keeping only the exceptions in some subfolder.
Since datacards can be applied only to the folder they are “saved” into, we end up having some copy again like illustrated below.
root (card0)
- folder1 (card1)
- folder2 (card1 copy)
- folder3
- folder4
folder3 and 4 gets the card 0 applied while there are folders like folder 1 and 2, that for practical reasons cannot be moved, but need to have the same specific datacard applied.
One approach I thought to workaround the limitation of having the card applied to the folder it was saved in would be to set a naming convention for datacard filenames: like DCARD001 and copyofDCARD001 for all the copy of that card scattered around. In that way there is more awarness of what is being revised.
Question1
It would be nice to show the card filename, its revision date (or rev nr) shown in one corner of the card itself and I am wondering if it was possible to link that value to a label to be sort of “automatic” without the need of a manual input.
Question2
There is no file version stored inside PDM for datacards files.
During maintenance if I want to rollback a previous datacard I should keep the file outside the vault or rename it before setting up a revised datacard.
I am leaning towards a rename system to briefly keep the old card versions inside the vault and rollback in case some issue is not detected in the test phase.
DCARD001.crd
DCARD001.250510 (creation date yymmdd instead of the extention )
Any demerit in doing so?
I have to rename the card from the saveas dialog in the card editor and delete the extensions the card is applied to to make it work.
Question3
Another issue I am running into is bugged tooltips: I really want to avoid documenting the datacards for the final user as the manual gets old, even if we read it, we tend to forget things. So if I put an explanation into each field tooltip everybody get a reminder of the purpose and use of each field.
Problem is the tooltip steal the focus from the input box (there is a BR opened) and the datacard become difficult to use and it could take too long to input the content due to that bug.
One way to work around that, I am planning to scrape the tooltips for each field in the card, instead I put a “?” label for each group of fields and explain them in group. think of a sort of help for the card.
Another way would be to add a tab with an actual help.
Any idea?
Note: the point of this kind of reasoning is that at some point I quit my position and someone must be able to run the PDM system without having to reverse engineer it like I am doing at the moment.