One of the advantages of using 2D drawings generated from a 3D model is that any changes made to the model mean that the drawing sheets are updated automatically. This is fine in theory.
My question is, how do people deal with drawing sheet revisions?
eg. I have 3D model A from which I generate views attached to sheets, with no revision. I can't update/amend 3D model A because these changes will propogate to the (non revised) sheets. This means that I have to copy Model A to create Model B which I then can update and use it's views to attached to rev. A drawings sheets.
Any thoughts/comments welcome.
Stuartw, Eric and everybody
Jeff Ashley pointed me to EDIT>SELECT BY ATTRIBUTES>>CRITERIA>>BUILDING>>DATE AND TIME
Anyone tested?
regards / Thomas Voghera
Sonya,
I think your last post is a good account of the unhappy transitional state that we are in.
1. Rollbacks:
Are seldom straightforward, which only reinforces the need for robust versioning tools. Since comparisons will be an essential to the versioning process, an effective way to switch between and overlay/compare different versions is needed. Have a look at these vids on CoCreate Model Manager.
Changes will be needed across multiple files, so a dynamically-updated dependency graph would be a good way to help keep track of the changes. ProjectWise / Kollabnet's Design Map could be integrated into the Project Explorer?
2. General arrangement v assembly v component drawings/models:
The MM vids also show that versioning and comparing segmented parts/components can be relatively straightforward and quick. The same approach can be scaled up to deal with assemblies or groups of components. This approach also allows revision numbers to be propagated bi-directionally between parent and child models in a reasonably comprehensible way. Some rules based processing will be needed.
Regardless, all of this can still leave check-in management so tedious that there most users will bypass and misuse the system.
Here, I think the problem for Mstn users is not having the flexibility to have multiple files open so that the changes can be 'played out' across multiple files. This way, the user can see the results before committing the changes. Minimising asynchronous, long transactions that burden users with subsequent transaction management has got to be a no-brainer.
CoCreate MM provides the option for 'top down' saves. This saves multiple 'activated' models to their individual files according to their dependencies, while versioning the changes according to user defined rules. Mstn really needs to follow thru on its hidden ability to save to multiple files.
CoCreate also highlights the advantage/need for component based structures over the existing layer based one for BIM, as far as versioning is concerned.
3. Data Integration:
There will be schedules, specs, change orders, photos, pdf's etc, in addition to dgn's. I think we agree that BIM means that coordination is a central goal, and must cover non-CAD data as well, especially if they can drive CAD data.
Data Group info needs to be granular enough to allow 'parameter' level versioning/tracking. Maybe it should follow OpenPlant PID in the way the parametric info is stored with the cell/component/dgn. I believe Speedikon 8.9 will use dgnlibs as the repository and can access the parametric data in referenced files. Structure's new ISM also uses the dgn as a repository. Write-enabled i-models?
I think a key part of versioning is how elements are locked or checked out. Mstn's locking is still file-based. There should be the option to check out elements out at the sub-file or component level. OpenPlant / PlantSpace's MCS workflow could be modified to restrict the granularity to the cell or named group or model level This will be a necessary precondition for keeping versioning manageable, I think.
4. Archiving:
The Packager does not seem to cover dataset/data group. And what about managing what is replaced when rolling back? Data will always be distributed across many files, which will make reinstating rollback info a time consuming and very error-prone, iterative process that will prolong user downtime.