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

Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X

Common space

Ketan_Lalcheta
19-Tanzanite

Common space

Hi

We can create workspace on the context and work on objects that need to be checked in or checked out within the context.

Now, if I have an assembly and its child part. Both of them need to be checked into different context. So, how to do this ?

If I create workspace on part , it can check in on one context.
Now, I want to check in assembly , I should create workspace on different context. But on this context's workspace; I don't have access to part of different context and without that , assembly is incomplete.

Any thoughts would be of great help.
ACCEPTED SOLUTION

Accepted Solutions

You might be interested in a few hours consulting on this - can arrange if you like.

 

In general:

- workspace can be on any context.  In the example, it was on the "HVT" context

- user can check in to any context for which they have create permission.

- may be some laborious effort required to select those objects in the workspace that need to be checked into a different context than the one on which the workspace has been created. Following that step, can select all remaining and check into the default context (the one on which the workspace is mapped)

- may be far more efficient to move after check in as others have suggested.

View solution in original post

12 REPLIES 12

User can select via folder icon where each object in the workspace is checked into - provided they have permission in that context.

I am sorry but I could not get you... Could you please elaborate it a bit ?

I have one part checked in into windchill already into a context.... Other assembly is there on local system. I am trying to open this assembly into Creo.... Both part and assembly need to check in , but assembly should be on different context than part's context..

Could you or anyone else can help me understand steps to be followed for assembly check in.

See attached brief screen captures.

Hope I understand the question correctly.

Hi

 

Appreciate your help on this.

 

Work space having CAD data has been created on which context? It is on THV or VHT?

 

Can I be able to set location of THV context from work space created on VHT context ?

Can I be able to set location of VHT context from work space created on THV context?

 

I got your point that custom check in should be done for CAD in this scenario, but above mentioned point is feasible?

 

Addition to this, both CAD you prepared are CAD part independent of each other. In my case, I would have a part and an assembly which has first part as dependent.What you mentioned is correct for dependent parts also?

 

It is not possible to load structured data if the user account does not have access to all required dependents in Windchill.  For this reason it is common to load data with an administrative account.

 

If loading data with an administrative account isn't possible, the easiest solution is to:

1. Load all parts and assemblies into the parts context using a user account.

2. From a standalone browser logged in with an administrative account, Move the assemblies to the assemblies context.

 

 

For loading purpose of CAD, I do have an administrative account.

Check-in must be a Custom Check-In, not automatic.

From there you cans et the folder for any NEW objects, like Mike shows.

You can not move an object by using check-in to a different folder.

To move an object, use a standalone browser and do a Move.

 

Let me ask one more question to you and all also....

Does this mean that context is already having provision to allow check-in from different workspaces ?

Does this mean below ?
- contextA and context B is there.
- by default , workspace on contextA can allow to do custom check in into contextA only..
- there should be some provision (what is I am curious about) on contextB to allow data to be pushed in from ContextA workspace....

Is this correct ?

I could see that I can check-in to both context from respective workspace , but not finding option of different context from other workspace for custom check-in folder path.

Please kindly bear with me for my basic questions.. I am mainly into toolkit customisation and very new to windchill.

Let me se if this helps you understand it.

 

You create WorkspaceA for ProductA and add an assembly to it. (I am using Product instead of Context, since it is really a product in Windchill terminology.)

 

You can create multiple Workspaces for each Product as long as they are unique names.

 

In WorkspaceA, you have the following new objects:

12345.prt

23456.prt

bolt_123,prt

washer_234.prt

56987.asm

56987.drw

 

In your Windchill commonspace structure, you want to put these objects in 2 folders. 

In folder ProductA\56987, you want:

12345.prt

23456.prt

56987.asm

56987.drw

In Library\StandardHardware, you want:

bolt_123,prt

washer_234.prt

 

During the custom check-in process, you can select which folder (Product or Library) that you want each object to be placed in. It doesn't matter if it is a product or library, you can check-in any object to any location as long as you have create permission on that folder.

 

Don't forget, you or your admin can always use the MOVE command to fix a mistaken checkin.

Thank you very much to all of you... It helped a lot....! Appreciate your time and effort.....

You might be interested in a few hours consulting on this - can arrange if you like.

 

In general:

- workspace can be on any context.  In the example, it was on the "HVT" context

- user can check in to any context for which they have create permission.

- may be some laborious effort required to select those objects in the workspace that need to be checked into a different context than the one on which the workspace has been created. Following that step, can select all remaining and check into the default context (the one on which the workspace is mapped)

- may be far more efficient to move after check in as others have suggested.

Announcements


Top Tags