Skip to main content
A
Amirtharaj_K17-Peridot
17-Peridot
September 25, 2023
Solved

Send to PDM

  • September 25, 2023
  • 1 reply
  • 2285 views

Hi Everyone,

 

I created one WT & CAD with associates each other with different folders. I used the "send to PDM" option to share in the product but it's saved in a single folder. There also i maintain the same folders & names.

 

Question 1: I want this automatic to be shared in the same folder as in the product when I create it in Project.

Question 2: Is any problem encountered when revising, renaming, or iterating on one side?

 

Thanks in Advance,

Amir

 

 

Best answer by Dobi

Are you wanting to do ECR/ECNs and promotions from a product context that include items from a project? Not sure that's possible in that sense of the word... 

 

Revisions are treated a little bit differently than just iterations. It's annoyting at times but I can see the thought process. If you're using promotions to release and then an ECN process triggered revise, you want that history where the rest of the version history is and not just a snippet of that history like is the case with a project. You can add a "share status" column to your version history table to see what is shared and what isn't in terms of versions. 

Dobi_1-1695738027243.png

 

And the project status table is also quite useful, I think. You can toggle share/checkout directly from there. 

Dobi_2-1695738092719.png

 

Rename: I think it's best to treat this without considering project contexts in general. If you create a new file in your workspace, you can rename it in your workspace UNTIL it's checked in. Once it's checked in, you can only rename in the product/library context where the file is. The same is true for data in a project. As long as it's in a project, it can be renamed there. Once you send to PDM (check in) you have to do that rename at the internal context (product or library). I also found that allowing moves in a project is not ideal because you can end up splitting project iteration history and it may make it difficult to know what's where. My preferred (if something was misplaced at share) was to just remove share and share again to the right location. Again, not ideal given the clunky interface and your first point with automatic folder selections.

 

You can have a project set up to do automatic syncs and updates. There's a preference in wt.properties that deteremines the schedule of the sync operations. https://support.ptc.com/help/windchill/r12.1.2.0/en/index.html#page/Windchill_Help_Center/interop/InteropShareAutoSynch.html

 

 

Dobi_0-1695737831259.png

 

For the last thing with users working with files that aren't latest, make sure that you have a table view that displays the "Latest" column and either sync/update regularly and/or train the users to ask the project be synced and updated when there's something out of date. If you have large amounts of data generated in the project AND a large amount of files shared but still worked on in a product, it just becomes a daily accounting exercise - administrative burden. Worst case, someone somewhere will need to edit some models to resolve any missing or deleted references. 

 

1 reply

D
17-Peridot
Dobi17-Peridot
17-Peridot
September 25, 2023

With a "Send to PDM", you pick where you send the files in your Product context individually. I think any sort of auto-selection of locations would need to be customized with code tied to the send to PDM action or some comparable user defined action.

 

Project and Product iterations and such are managed separately to a point. 

Revisions: A new revision of a file in a product context is not automatically shared to a project.

Renames: 

  • If you create a new file in a project, you may as well treat this as a new file in your workspace. You can rename it at the project level all you want. When you go to send to PDM, Windchill will check for internal naming conflicts and you'll then have to resolve those (via rename at the project level) before you can complete the send to PDM action. Once the file is in a product/library context, the name is locked there and can't be edited at the project level (i think)
  • If a file exists in a product, that's where the name is controlled so that's where the rename has to occur. This is also permission enforced. Users in a project context may not have "Modify Identity" permissions granted to a product context where the file resides internally

Iterating: Projects maintain their own iterations for data edited there. Products have their own. For bits that are shared between the two: 

  • "Add to Project" with PDM Checkout option is the same as "Add to Workspace" and "Checkout". Except here, you're checking out the file to the Project context for subsequent editing and the file is meanwhile locked for editing in the product.
  • Once shared with PDM Checkout, the iterations at that revision level of the shared file are maintained within the project context separately and ONLY live there. 
  • "Send to PDM" is a project to product check-in operation so the latest iteration of the project file becomes the next iteration of the product file. At that point, you have a version history in the product AND a version history at a pericular share action in the project. 

As long as wrap your head around the actions, there aren't problems with this flow. It gets tricky with updating the project. Are you doing manual updates or scheduled syncs? 

One thing that becomes problematic is users continuing to work on files that aren't latest or haven't been updated in a while. It becomes increasingly challenging to get things to send to PDM if there isn't careful maintenance of the project commonspaces. 

    A
    Amirtharaj_K17-PeridotAuthor
    17-Peridot
    September 26, 2023

    Thanks you for the relay Mr. Dobi,

     

    It's a Manual & but if we maintain in a Project Management Folder i can't do ECN or ECR, Promotion request, & many more.

    Revisions: A new revision of a file in a product context is not automatically shared to a project. But both or same link right. Then why had a this much complicate.

    Renames: If that user have a permission for rename, move and all access means it's update in Project Management data also.

    I want more explanation for manual updates or scheduled syncs

     

    How we can find that One thing that becomes problematic is users continuing to work on files that aren't latest or haven't been updated in a while. It becomes increasingly challenging to get things to send to PDM.

     

    Regards,

    Amir

    D
    17-Peridot
    Dobi17-PeridotAnswer
    17-Peridot
    September 26, 2023

    Are you wanting to do ECR/ECNs and promotions from a product context that include items from a project? Not sure that's possible in that sense of the word... 

     

    Revisions are treated a little bit differently than just iterations. It's annoyting at times but I can see the thought process. If you're using promotions to release and then an ECN process triggered revise, you want that history where the rest of the version history is and not just a snippet of that history like is the case with a project. You can add a "share status" column to your version history table to see what is shared and what isn't in terms of versions. 

    Dobi_1-1695738027243.png

     

    And the project status table is also quite useful, I think. You can toggle share/checkout directly from there. 

    Dobi_2-1695738092719.png

     

    Rename: I think it's best to treat this without considering project contexts in general. If you create a new file in your workspace, you can rename it in your workspace UNTIL it's checked in. Once it's checked in, you can only rename in the product/library context where the file is. The same is true for data in a project. As long as it's in a project, it can be renamed there. Once you send to PDM (check in) you have to do that rename at the internal context (product or library). I also found that allowing moves in a project is not ideal because you can end up splitting project iteration history and it may make it difficult to know what's where. My preferred (if something was misplaced at share) was to just remove share and share again to the right location. Again, not ideal given the clunky interface and your first point with automatic folder selections.

     

    You can have a project set up to do automatic syncs and updates. There's a preference in wt.properties that deteremines the schedule of the sync operations. https://support.ptc.com/help/windchill/r12.1.2.0/en/index.html#page/Windchill_Help_Center/interop/InteropShareAutoSynch.html

     

     

    Dobi_0-1695737831259.png

     

    For the last thing with users working with files that aren't latest, make sure that you have a table view that displays the "Latest" column and either sync/update regularly and/or train the users to ask the project be synced and updated when there's something out of date. If you have large amounts of data generated in the project AND a large amount of files shared but still worked on in a product, it just becomes a daily accounting exercise - administrative burden. Worst case, someone somewhere will need to edit some models to resolve any missing or deleted references. 

     

    Terms & ConditionsAccessibility statement