Using "WIndchill Packages" would seem to be the approach BUT to move CREO designs from a 11.1 instance to an 11.2 instance fails on loading Received Package because of Windchill Version difference. Where in any documentation does it show that that configuration will not allow transfer. I don't see a reasonable use case which would put a company and all its collaboration partners (vendors) maintain the same revision of WIndchill.
Trying to move designs from one WIndchill to another keeping correct version number and lifecycle state. Receiving system is configured to match CREO configuration except for being different WIndchill Version.
Exporting and importing designs between Windchill systems will result in the import system seeing the files as new and thus the reset.
Have you tired using ProjectLink to share files between the 2 systems?
I which way. THese are separate system, so I have to export/import in some way.
What ProjectLink capabilities are you talking about.
I've tried packages and that doesn't work. (issues with Windchill Versions (must align) and requires PLM Connector (even if doing manually)
I've tried tech support which says create new non-PDM attribute that matches exiting PTC_WM_VERSION. That only fixes the version issue, not the lifecycle state issue. It also doesn't solve problem when new REVISON comes from vendor. No way to bring in 2nd version (wants to only be a new iteration).
surprised that this isn't an issue with more customers. Basically the use case comes down to this.
1) receive revision "X" part and drawing from vendor that used windchill
2) put in Windchill so that revisions are the same as vendor provided (especially if REV is on face of drawing)
3)receive revision "Z" part and drawing from vendor that used windchill
3) put in Windchill revision "Z" (etc) as "Z" revision for same reason as 2)
I would suggest:
If you have many objects It would be useful to have some automation
I would suggest:
- Make a list of objects to be exported with desired revisions and states
- Export to Windows folders (backup or Workspace exports)
- If you need different parameters/attributes convert them (maybe with some mapkey)
- Import into new system (everything is state Design revision 0)
- Set revisions and states to the ones you got in step 1
If you have many objects It would be useful to have some automation
Thanks for this. This worked exactly as expected.
I've tried every version of sharing including ProjectLink.
I was able to export then import to a ProjectLink Project. All designs imported to Project with the correct revision, the correct lifecycle, and the correct revision.
I was even able to open in a project workspace and was able to iterate design and it move to next version (ie. 3.2 to 3.3).
However, as soon as I did "Send to PDM", it replaced all the values with initial values (rev 1, WIP state, etc), even though both locations used the same OIR and had the same lifecycles and revisions.
Moral of the story is: There seems to be no way to correctly share data between two Windchill systems without "corrupting" the attribute data.
I think there is also the possibility to export 2 Windchill systems, merge them and then import them back. In that case the revisions, etc would be maintained.
But that is probably overkill in most cases.
Versioning changes between ProjectLink and PDMLink because of how Windchill keeps track of history in the two different modules. Once you send to PDM from ProjectLink you would have to manually set revisions and life cycle states to the incoming files if they are different than default. Your use case is of getting data from one Windchill system and putting it into another system altogether. Unless the two systems are synced you're presenting new data to one system so the OIRs will apply. Moving pertinent parameters to attributers is likely the way to go.
I am curious, though, on how you were able to pass data from one Windchill instance into a different Windchill instance through projectLink, though...
I'm curious about this. Can you actually share data between two different Windchill instances (https://windchil1 and https://windchill2 ) through ProjectLink?
ProjectLink, as a module, works within a single instance for sharing data from PDMLink (Product, Library, etc.) into ProjectLink and back. How do you share to a different Windchill's ProjectLink?
For the case that you describe, it would seem that it's essential to do the following:
- Use ProjectLink in your system and have the vendors work in your ProjectLink, not their own WIndchill PDMLink
- Check out the data to the Project, rather than share it. This guarantees that the data will not be changed on your side while the vendor is working.
- Once the vendor is done, Check back into your PDMLink.
Seems like a nightmare to keep straight, but this may help.
If you're using Creo (rather than a 3rd party CAD that requires WGM), offline workspaces also can be used. Add the data to a workspace and export it to an offline file. Check out what the vendor should change. The vendor updates within that, they you simply check in the changes (and any new created by vendor).
That's the use case today and that assumes that everything is running on a single instance.
Our vendors work in our instance today and we share data to ProjectLink for them to access. On their end (for the ones that use Windchill within their own companies as well) that means they have multiple Windchill servers connected. That's all well and good and works.
My question is whether I can share data from say a PDMLink in Windchill instance 1 to ProjectLink in Windchill instance 2 by just doing an Add to Project action?
For example: say you and I are working together. You have your instance of Windchill running and I have my instance of Windchill running. They are separate.
I want us to share data through ProjectLink so I set up a Project context in my instance and give you access to it. I can share data to the Project context from my PDM because it's in my Windchill instance.
You can get data from my Project context by logging into my Windchill instance and working within my Project context.
However, if you want to share data into that same Project context in my Windchill instance from your PDM - which is in your Windchill instance - how do you do it without exporting and importing?
Nice diagram - very helpful.
To my knowledge there is no way to do that. Packages were created for that primary use case, but as you note (w detail) there are some challenges.
If vendors are able to work within your system, that is definitely preferred (for you - may have challenges for them).
Good use case for PTC to consider, but may be hard to justify the cost of development, testing, etc.
Alas, I was hoping for a different answer 🙂
Packages aren't as clean as "Add to Project". For us there's a specific network restriction that's having me ponder multiple Windchill instances but without the ability to cleanly share between the two, it's unlikely worth the trouble.
Thanks for the conversation. This was helpful.
Mike is 100% correct. Windchill does not allow direct sharing between different Windchill instances. The Send to Project action is only available for the active Windchill system, not a secondary system.
Supplier collaboration is not easy and with an additional Windchill system, its even more complex for you.
The only solution available from PTC is Replication Packages, which will allow you to package, export, transfer and import into a different Windchill system. Its not intended to support high iteration supplier collaboration, its meant to replicate data from one system to another.
I ran into this a while back and the solution was the following.
I wrote a Java utility that does two things:
1. Creates a log of the metadata of the Persistables in a Package
2. Set the metadata of the Persistable using the log generated in step 1.
I guess you can see where this is going.
1. Create a Package with the Creo data
2. Run a java script the script that gets the metadate
3. Send Package
4. Target Windchill site imports the Package
5. Target Windchill site run the utility which reads the log and resets, if necessary the name, revision and state.
So far it has worked well and even considers if the new data is at a later revision that the existing data.
For example, the target system's latest version is B.3. After Package import we now have B.4 but according to the log the revision should be D not B. The utility fixes this so now the latest is D.1
Ultimately, I created a custom action that the user could run from the Package info page to create the log and have it automatically attached to the Package's "Include in Delivery Attachments".
So far so it's worked well.