The file is not rebuilt

[SPerman]

I am in the process of moving all of my files into PDM. I am trying to check in my files, and I'm getting a lot of "The file is not rebuilt" errors. There are dozens if not hundreds of assemblies in this condition. I cannot open each assembly individually to solve this problem. I've got a subscription to #task and I've tried running a couple of their built in macros to try and make this problem go away, but nothing is working. Are there any suggestions on how to solve this problem?

[bnemec]

I am in the process of moving all of my files into PDM.

I am trying to check in my files, and I'm getting a lot of "The file is not rebuilt" errors. There are dozens if not hundreds of assemblies in this condition. I cannot open each assembly individually to solve this problem. I've got a subscription to #task and I've tried running a couple of their built in macros to try and make this problem go away, but nothing is working. Are there any suggestions on how to solve this problem?

I think what you are looking for is in user/group properties (not settings) in the Admin Tool.

Is that box checked?

[SPerman]

That box isn't checked for any user or group that I can find. I was hoping it would be that simple.

[bnemec]

That box isn't checked for any user or group that I can find. I was hoping it would be that simple.

Right. Sorry for stating the obvious.

You said you're getting errors. I assumed for some files in the Reference File Dialog. Is that where you're seeing them or are you getting an error dialog popping up?

[SPerman]

I guess I am getting warnings that I can just ignore. I'm just learning my way around PDM, so I'm sure I will make a few dumb mistakes.

[Alin]

I am in the process of moving all of my files into PDM. I am trying to check in my files, and I'm getting a lot of "The file is not rebuilt" errors. There are dozens if not hundreds of assemblies in this condition. I cannot open each assembly individually to solve this problem. I've got a subscription to #task and I've tried running a couple of their built in macros to try and make this problem go away, but nothing is working. Are there any suggestions on how to solve this problem?

CAD+ could do the trick. It can process all files in the order of their dependencies.

Alternatively, you can use the PDM update tool to achieve the same goal.

[bnemec]

I guess I am getting warnings that I can just ignore. I'm just learning my way around PDM, so I'm sure I will make a few dumb mistakes.

Oh man, I wish I had only made a few. I'm getting it down to a few per month now, mostly because someone else is taking over PDM Admin job. I was mistaking hourly in the beginning. I found many many things to NOT do in PDM.

[the_h4mmer]

I guess I am getting warnings that I can just ignore. I'm just learning my way around PDM, so I'm sure I will make a few dumb mistakes.

You can 'technically' ignore them, however I would say you may not want to (I know I can't at my organization). My organization insists on keeping Revision on the BOM for parts in an assembly, so if you do not rebuild everything from the bottom up, you will not show the correct Revision in the BOM table at the top-level assembly. Also, depending on what your approval process looks like, your assembly may end up referencing an older version of a part file if the part isn't released BEFORE the assembly, since the file version iterates when updating variables (such as revision). There are many other reasons to ensure everything is properly rebuilt, but I'm sure there are many who would argue that it's not required as the model still "looks" right; I'm more of the mind that the model should be right.

In Solidworks Task Scheduler, there is a batch "Update file references" which should rebuild an assembly and all related files (you'll have to check them out first). I've tried using this, but so many of our models are broken for other reasons, that it fails somewhere along the updating process.

I actually enforce the "Can't check in if file is not rebuilt" setting in PDM. This way I can avoid any new files from being added to the vault that are not properly updated. I've read that others do something similar by requiring part models to have Features Frozen using the Freeze bar (locks rebuilding those features), but forcing users to ensure they have rebuilt files before check in requires less back-and-forth.

[jcapriotti]

You can 'technically' ignore them, however I would say you may not want to (I know I can't at my organization). My organization insists on keeping Revision on the BOM for parts in an assembly, so if you do not rebuild everything from the bottom up, you will not show the correct Revision in the BOM table at the top-level assembly. Also, depending on what your approval process looks like, your assembly may end up referencing an older version of a part file if the part isn't released BEFORE the assembly, since the file version iterates when updating variables (such as revision). There are many other reasons to ensure everything is properly rebuilt, but I'm sure there are many who would argue that it's not required as the model still "looks" right; I'm more of the mind that the model should be right.

It's a challenge for us due to the size of our assemblies and the sharing of components amongst products. There are over a 100 ECOs inflight at any given time adding/changing/obsoleting parts and assemblies so updating all assemblies a part is used in for minor changes would bring the whole ECO system to a screeching halt.

[the_h4mmer]

It's a challenge for us due to the size of our assemblies and the sharing of components amongst products. There are over a 100 ECOs inflight at any given time adding/changing/obsoleting parts and assemblies so updating all assemblies a part is used in for minor changes would bring the whole ECO system to a screeching halt.

That's exactly it. It does become a trade off of what is the organization feel more comfortable with? Personally where I'm at, our vault is so broken and problematic that I told everyone there is no choice but to slow things down and fix everything part-by-part. With ECOs, one of the first steps in the eval process is to do a discovery session to find out what files will require updating (the PDM Where Used function is great for this). The risk here is that if someone changes the model for a part, but doesn't bother to update the drawing, then the drawing will be out of date and same with every assembly model and drawing it's used in. At the very least, you'll probably need to do some amount of updating to ensure that anything that needs the update is correct; for example a part that had a clearance issue in an assembly, the part and its drawing need updating but so will the assembly and its drawing.

As an aside, my company has driven their model design by the ERP system and build process, not actually good design practices, so last year when they wanted to change 2 screws in the ~12 top-level products; 106 documents would have needed updating. I brought this up at the ECR review and told the committee it would take weeks to months to make this happen if fully dedicated to the task; we didn't end up making the change but mostly for other reasons. Now I'm preparing for the battle to divorce the modeling practices from the ERP system.

[bnemec]

That's exactly it. It does become a trade off of what is the organization feel more comfortable with? Personally where I'm at, our vault is so broken and problematic that I told everyone there is no choice but to slow things down and fix everything part-by-part. With ECOs, one of the first steps in the eval process is to do a discovery session to find out what files will require updating (the PDM Where Used function is great for this). The risk here is that if someone changes the model for a part, but doesn't bother to update the drawing, then the drawing will be out of date and same with every assembly model and drawing it's used in. At the very least, you'll probably need to do some amount of updating to ensure that anything that needs the update is correct; for example a part that had a clearance issue in an assembly, the part and its drawing need updating but so will the assembly and its drawing.

As an aside, my company has driven their model design by the ERP system and build process, not actually good design practices, so last year when they wanted to change 2 screws in the ~12 top-level products; 106 documents would have needed updating. I brought this up at the ECR review and told the committee it would take weeks to months to make this happen if fully dedicated to the task; we didn't end up making the change but mostly for other reasons. Now I'm preparing for the battle to divorce the modeling practices from the ERP system.

@the_h4mmer, do I know you? If you're the guy we hired to take over PDM Admin role here you've blown your cover of the clever alias.

[the_h4mmer]

@the_h4mmer, do I know you? If you're the guy we hired to take over PDM Admin role here you've blown your cover of the clever alias.

HA! I don't believe so, I'm based on the East Coast and work for a very small organization That would have been quite funny tho.

Curious, why do you ask? Do I sound like someone you know or work with?

[bnemec]

HA! I don't believe so, I'm based on the East Coast and work for a very small organization That would have been quite funny tho.

Curious, why do you ask? Do I sound like someone you know or work with?

We hired someone to replace me as PDM Admin ~8 months ago, I kinda need to get back to design work and we'll need a full time PDM Admin for a couple more years. Reading your comments about coming into a Vault behind the guy who set it up and didn't know what he was doing just made me think of him. Poor guy. He's a good sport though.

[jcapriotti]

We hired someone to replace me as PDM Admin ~8 months ago, I kinda need to get back to design work and we'll need a full time PDM Admin for a couple more years. Reading your comments about coming into a Vault behind the guy who set it up and didn't know what he was doing just made me think of him. Poor guy. He's a good sport though.

Why are still hanging around this forum......you should be over at General Engineering and Design

[bnemec]

Why are still hanging around this forum......you should be over at General Engineering and Design

RunForest.gif (2.75 MiB) Viewed 7900 times

[the_h4mmer]

We hired someone to replace me as PDM Admin ~8 months ago, I kinda need to get back to design work and we'll need a full time PDM Admin for a couple more years. Reading your comments about coming into a Vault behind the guy who set it up and didn't know what he was doing just made me think of him. Poor guy. He's a good sport though.

Ah fair, no the person I followed didn't know anything about PDM or document/revision control. To be fair, it's likely they didn't have any opportunity to learn, but it's really unsettling to check a design file history and find that a Production Released assembly (and all the parts, which were not all released) was checked out, one part of the assembly was changed (so much it should've been a new part), and then checked back in, with the note reading "changed baseplate." Then I find out that the same part was forced to a released state (by this same individual), without review so it could be manufactured, which was later found out that the change resulted in 500 machined parts to become scrap (~$50k total).

Now I get to fight with management who thinks that PDM administration is a 'side' responsibility and not business critical. Every time this argument comes up, I point to that situation, and they blame the person can't fathom the fact that in all likelihood, they pushed so hard and that engineer just "made it so" since they gave the role of PDM admin to the very same person who needs to be kept in check.

To try to pull the conversation back on to topic, this lack of discipline and document control led to the entire vault showing as "File is not rebuilt." I told everyone we either are going to start 100% from scratch on all designs (what I wanted to do since the designs were a disaster as well) or I unrelease everything and we fix, update, review, and release everything from the bottom up. They went for the latter, but I'm still juggling that with multiple design projects and support; but hey I almost have two critical subassemblies and one top level assembly fully released with no rebuild warnings!

yay....progress!

Unfortunately these assemblies are riddled with out-of-context broken references (not even for something in the vault)

[jcapriotti]

Now I get to fight with management who thinks that PDM administration is a 'side' responsibility and not business critical. Every time this argument comes up, I point to that situation, and they blame the person can't fathom the fact that in all likelihood, they pushed so hard and that engineer just "made it so" since they gave the role of PDM admin to the very same person who needs to be kept in check.

I fought this for years where I work......I even left after years of trying to be a designer and CAD/PDM admin at the same time and telling them that we need someone full time. They asked me back after 3 years, and I told them I would only come back as a full time CAD Admin.

I had the "blame the person" argument with our President of engineering. I wanted to make a backup external hard drive standard for all engineering laptops. I told him that PDM stores checked out files on the C drive until the user checks them in. If the user loses their hard drive, those files are toast. He said they need to check them in everyday, I told him that I've told the engineers that numerous times, but they forget. He was like, if they lose files then they will be fired. I said that doesn't change the fact that in some cases you could lose a major part of the design, fired or not, the files are gone. $6000 grand for hard drives was too much for him........we wasted that much in 3 or 4 engineering manager meetings that last 2 hours.

[the_h4mmer]

@jcapriotti that's rough and the cost of HDDs for backups is not that expensive...guess it's easier to blame the person than it is to allocate budget; seems like the Peter Principle. My favorite is that we get hired for our "expertise and knowledge" yet, more often than not, when we say, "this is important" it's ignored because it isn't a priority for management (then why do you need me?).

Would love to hear a manager's perspective on any of this, do we know any Engineering Managers and/or Leadership members on the forums to tag? In all honesty, I truly want to understand. (maybe should start a new thread tho, I feel bad for hijacking this one)

[Willmsy]

It's a challenge for us due to the size of our assemblies and the sharing of components amongst products. There are over a 100 ECOs inflight at any given time adding/changing/obsoleting parts and assemblies so updating all assemblies a part is used in for minor changes would bring the whole ECO system to a screeching halt.

I am in the process of implementing 2 vaults and we are having the same issue. Our assemblies are hundreds of parts and most often it is the fasteners and purchased components that are causing the issue. We have run the File Version Update tool and that worked for the files that were in the vault, but when we added new assemblies, BAM! the warning was back... I don't want to run that tool every time we add a new assembly. There are many files that are linked to CO's and in change in our PLM system.

The VAR helps a bit but it always goes back to wanting to sell us something to do a migration.

[mp3-250]

Skipping rebuilds in PDM could and will lead to a lot of unpleasant things.
our best practice so far: starting from the single part at the very bottom leaf of the assembly tree, rebuild, save and put the data in a locked state so no unwanted edits allowed when the related assembly is loaded.
this operation could be automated imho.

when you have the lowest level of parts rebuilt and locked (usually hardware and catalog parts) start with the sub assemblies at the bottom of the tree and go up rebuilding and locking sub assemblies, but do not lock them until every part inside is locked. we had some very unpleasant surprise with partially locked subassemblies, so if you are doing the job do it properly.
while this operation could be automatized I think an engineer supervision is needed.
it depends a lot on your company wokflow, data structure (shared units, sUb assemblies vs all project in one folder etc), but in the end someone must look at the data and say "ok this one is finished" otherwise it will blow up in your face at some point. and you could find yoirself rebuilding a vault from scratch again.
we are at the 2nd rebuild facing a 3rd one due the the past admin "quick and dirt" decisions. this on top the usual SW bugs and user "techniques" that are already blowing up our legacy 3d models...

[bnemec]

Skipping rebuilds in PDM could and will lead to a lot of unpleasant things.
our best practice so far: starting from the single part at the very bottom leaf of the assembly tree, rebuild, save and put the data in a locked state so no unwanted edits allowed when the related assembly is loaded.
this operation could be automated imho.

when you have the lowest level of parts rebuilt and locked (usually hardware and catalog parts) start with the sub assemblies at the bottom of the tree and go up rebuilding and locking sub assemblies, but do not lock them until every part inside is locked. we had some very unpleasant surprise with partially locked subassemblies, so if you are doing the job do it properly.
while this operation could be automatized I think an engineer supervision is needed.
it depends a lot on your company wokflow, data structure (shared units, sUb assemblies vs all project in one folder etc), but in the end someone must look at the data and say "ok this one is finished" otherwise it will blow up in your face at some point. and you could find yoirself rebuilding a vault from scratch again.
we are at the 2nd rebuild facing a 3rd one due the the past admin "quick and dirt" decisions. this on top the usual SW bugs and user "techniques" that are already blowing up our legacy 3d models...

Are you saying no file in the vault should want to rebuild when it's opened? Ie. every single file in the vault should not request a rebuild upon opening?

[mp3-250]

@bnemec locked (official-released) data should be rebuilt before lockIng them. at least.

but I had some case of an engineer not rebuilding assemblies.

Engineer A checked in an WIP assy (looking from explorer it had only 2 components in the pdm BOM in fact there were dozen in multiple sub assys inside the 3d data)

As result engineer B with *read only* permission in the vault loaded that assy and was not able to see a new added part that was supposed to be there in the latest version.

Problem was SW loaded the not rebuilt assy found it broken and modified it locally somehow so engineet B "latest version" was not the same as the server one (green clock icon) and the new added part was not referenced anywhere inside the assy.

I made engineer A load the broken assy he made, check it out, rebuild it from the leaf and check in again.
engineer B was able to see the assy as designed with the real latest version from the server.

My explaination is engineer B was stuck in a loop: he took the latest version from the server (broken) SW overwrote it creating a local new version on the spot (triggering the "newer" flag on its pc; or better a "different from current and past versions stored in the server" flag) remember this user was supposed to read only the vault data.
And even rebuilding the WIP assy locally on his pc was useless.

PDM is a nightmare without proper settings and discipline.

[jcapriotti]

@mp3-250 The read-only user having a newer "local (green icon)" version without it being checked out is either a bug, or the user manually removed the read-only flag on the file.

The bug being that sometimes the system may fail to reapply the read-only flag to the local file on check-in, if the user never had checkout rights then that may not be the case here. I've seen some programs (like Altium) uncheck the read-only flag themselves but not SolidWorks or office docs. The other way I've seen this happen is the user right clicks the file, select properties and removes the read-only flag themselves without checking out the file. Then they can write to their local copy.

[mp3-250]

Engineer B uses SW to check A design he has not interest or skill to tamper the system, he mesasure here and there nothing more.

it could be a bug, but when I made engineer A rebuild its files the BOM tab magically shown dozen of files and B was immediately able to take the latest version as expected.

very likely A put together the top assy checked in once without rebuilding at all than modified only one sub assy witthout touching the parents.

I should have time I investigate properly, but all the hours I spent in debugging SW and PDM (like their bugged reference scripts in task) are hardly paying back my salary TBH.
I would prefere to solve problems with SW rather than solving SW problems.
sorry for the rant

[bnemec]

@bnemec locked (official-released) data should be rebuilt before lockIng them. at least.

but I had some case of an engineer not rebuilding assemblies.

Engineer A checked in an WIP assy (looking from explorer it had only 2 components in the pdm BOM in fact there were dozen in multiple sub assys inside the 3d data)

As result engineer B with *read only* permission in the vault loaded that assy and was not able to see a new added part that was supposed to be there in the latest version.

Problem was SW loaded the not rebuilt assy found it broken and modified it locally somehow so engineet B "latest version" was not the same as the server one (green clock icon) and the new added part was not referenced anywhere inside the assy.

I made engineer A load the broken assy he made, check it out, rebuild it from the leaf and check in again.
engineer B was able to see the assy as designed with the real latest version from the server.

My explaination is engineer B was stuck in a loop: he took the latest version from the server (broken) SW overwrote it creating a local new version on the spot (triggering the "newer" flag on its pc; or better a "different from current and past versions stored in the server" flag) remember this user was supposed to read only the vault data.
And even rebuilding the WIP assy locally on his pc was useless.

PDM is a nightmare without proper settings and discipline.

I'm pretty sure that if B already had the assembly file and it's refs in local cache when A made the changes then B would need to actively get latest to see the changes.

When user B opens the file (not checked out so it's read only) but SW will still update if it thinks it's needed, then they have changes, but that user should not be able to save the file to their local cache. So user B can see all kinds of changes, but cannot save them. That is tough for some users to grasp that what they see is not necessarily exactly what is checked in.

Let me ask, do you ever change a component (transition to WIP and check out and check back in) that is used by a released assembly that cannot be checked out, even by A due to it's state?