cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Setting Workspaces to Read Only - Good or Bad

Newbie

Setting Workspaces to Read Only - Good or Bad

Hey all,

I have questions about Read Only Status in Workspaces.

I've looked through the exploder archives, and I did find some info about
setting objects in Workspaces to Read Only but mostly in relation to Family
Tables (as in don't set Family Table member to Read Only)

Our users have drifted into the practice of immediately setting all the
objects in their WS to Read Only immediately after an Check-Out, leaving
only the files that they intend to modify. We are talking 3000-4000
objects in a WS including Family Table Instances.

The theory is that Pro "pluses" stuff all the time - sometimes seemingly at
random, and plus-modified objects have to be checked into Commonspace. This
might not be a good thing if some of those objects are Released. The theory
continues that Read Only prevents the random plusing. I feel that this is a
terrible practice because Pro insists that objects be modified for a
variety of reasons and you have to let Pro do its work. You can't fake it
out. You can Sync with Commonspace to write over the plus-modified parts
(another adopted practice), but that will undo things and cause more
problems. In fact we think it's a factor in our Check-In errors on these
large WS. Yes we know there's workarounds and suggested techniques, but
simply put my question is:

Use Read Only? Don't use Read Only?

The result of NOT using Read Only is that hundreds of objects become
plus-modified in the daily activity in a WS. The user has to deal with all
of those objects - not easy if the modified objects were Released. It's
hard to explain to the boss that the simple dimensional change on the
drawing caused 40 objects to become plus modified because they're all newly
regenerated.

Second Question:

Didn't there used to be an icon for when an object was set to Read Only and
Pro insisted on modifying it? The part icon would show a little do-dad
next to it signifying that even though this object is Read Only, it really
must be regenerated.

We seem to remember something like this in earlier versions of Intralink
3.0, but it no longer appears to be the case in Intralink 3.3 2003290 (our
current version). We also on WF1 - M200.

Thanks in advance for all the responses. The summary will of course follow.

Ray Ford
Engineering Process Specialist
Solar Turbines, Inc
San Diego
3 REPLIES 3

RE: Setting Workspaces to Read Only - Good or Bad

Pro/E does mark things up on what appears to be a "random" fashion but more often than not it has something to do with what the user is attempting to do. Common things that cause other objects to be marked up in the WS but have absolutely no impact on the assembly include:

1. Using "Save Status" after turning layers off (such as datums) at the assembly level - this will turn turn them off in all parts and save them that way. Setting the parts to read only will prevent this.

2. Forced Regenerations will cause "modified" parts as well (Regenerate > automatic)

3. External references cause "modified" parts - these are created most frequently during "top down" design

4. Relations using "IF" statements cause parts to me modified even if the values do not change

5. Mass property calculations - if you perform a model analysis to compute the weight, CG, etc and the mass properties have not been calculated recently or at all on the assy's components, then they must be calculated, which causes a mark up "modified" in the WS

6. ModelCheck - if you use this as a gatekeeper it will mark items modified if you select "all levels" because it changes the date it was ran on the components

7. Yes, Pro/E marks things "modified" sometimes and it is difficult to determine what caused this.

I have not ran into a situation where updating a "modified" that I did not intentionally change caused the assembly to fail. I can say the same about changing the WS status to Read Only.

If items are "released" control this through "read only" access in CS combined with setting local preferences to "Error" without checkin authorizations. You do not want parts inadvertently changing after they have been released.

Being able to change the WS to "read only" in the WS is intended functionality in that you are telling Intralink that no matter what Pro/E says, you do not want this file to change.


Highlighted

Re: Setting Workspaces to Read Only - Good or Bad

How about setting "regenerate_read_only_objects no"? That's what I
started doing lately. That takes care of regenerating of assemblies and
of referenced parts. Seems to cure the problem and speed up regens.

You do get an annoying warning dialog every time it skips a part. I'd
rather it just mention it in the message area, but that's all right.

- Wallace


Ray J. Ford wrote:
>
>
>
>
> Hey all,
>
> I have questions about Read Only Status in Workspaces.
>
> I've looked through the exploder archives, and I did find some info about
> setting objects in Workspaces to Read Only but mostly in relation to Family
> Tables (as in don't set Family Table member to Read Only)
>
> Our users have drifted into the practice of immediately setting all the
> objects in their WS to Read Only immediately after an Check-Out, leaving
> only the files that they intend to modify. We are talking 3000-4000
> objects in a WS including Family Table Instances.
>
> The theory is that Pro "pluses" stuff all the time - sometimes seemingly at
> random, and plus-modified objects have to be checked into Commonspace. This
> might not be a good thing if some of those objects are Released. The theory
> continues that Read Only prevents the random plusing. I feel that this is a
> terrible practice because Pro insists that objects be modified for a
> variety of reasons and you have to let Pro do its work. You can't fake it
> out. You can Sync with Commonspace to write over the plus-modified parts
> (another adopted practice), but that will undo things and cause more
> problems. In fact we think it's a factor in our Check-In errors on these
> large WS. Yes we know there's workarounds and suggested techniques, but
> simply put my question is:
>
> Use Read Only? Don't use Read Only?
>
> The result of NOT using Read Only is that hundreds of objects become
> plus-modified in the daily activity in a WS. The user has to deal with all
> of those objects - not easy if the modified objects were Released. It's
> hard to explain to the boss that the simple dimensional change on the
> drawing caused 40 objects to become plus modified because they're all newly
> regenerated.
>
> Second Question:
>
> Didn't there used to be an icon for when an object was set to Read Only and
> Pro insisted on modifying it? The part icon would show a little do-dad
> next to it signifying that even though this object is Read Only, it really
> must be regenerated.
>
> We seem to remember something like this in earlier versions of Intralink
> 3.0, but it no longer appears to be the case in Intralink 3.3 2003290 (our
> current version). We also on WF1 - M200.
>
> Thanks in advance for all the responses. The summary will of course follow.
>
> Ray Ford
> Engineering Process Specialist
> Solar Turbines, Inc
> San Diego
>
>
>

Re: Setting Workspaces to Read Only - Good or Bad

The only real negative to read-only is that it prevents flexible
components from working properly. This is because when an assembly with
a flexible component is opened, the flexible dimension, parameter, or
feature causes the flexible component to be regenerated to take its
"flexible" shape in the assembly. Read-only prevents this from
happening.

Eric Boone
Senior Design Engineer
Closure Medical Corporation
10900 73rd Ave N, Suite 110
Maple Grove, MN 55369