Yes Vlad, I was in the room during the January TC meeting you are referring to and very interested to see how it works! I look forward to hearing about the updates.
If you recall there was a customer in the room that stated they have turned off IA creation because they are having issues. (don't rememeber the specifics) Hopefully, they have them resolved by the June 7th so we can hear how great they are! Our company needs to hear success from other customers before we even entertain testing them.
Please elaborate on any specific problem you see on Windchill with instance accelerators...
Vlad, I just saw this come through on the Creo Community. Seems very relevant.
We use quite a bit of family tables for our PCB components so there could literally be a 1k of parts for one resistor. Looking back at that we probably should have went a different route.
The fix to the issue that I outlined above was a configuration setting. I had save_instance_accelerator set to always. Which prevented from saving. I changed to NONE and it fixed the issue with WC and Creo saving these assemblies and parts with family tables. It solved my issue.
The comment was originally posted to this topic: Saving assembly conflict message ask to check out parts
(It looks like maybe it has since been deleted.)
Correction, looks like it's been moved here:
Thanks for shedding the light on the source of the issue. If this is the only (or major) problem of .xpr / .xas files usage there might be a cure to it.
I have to say, that reading reference case at https://www.ptcusercommunity.com/message/407665?et=watches.email.thread#407665 does not provide the full info since it is not clear if accelerators existed before, were they up to date or not, and what were the nature of the changes that user did in Creo session before pushing Save. Having the model + trail would be the best.
In general :
save_instance_accelerator = always : really implies that accelerator files will try to update (save, and also force generic storage !) and will be created (if not existed beforehand) upon any Save attempt. This option can make trouble if this is library object forbidden for save. For e.g. your library part has family table, and had no accelerator files - Save - it will try to generate multiple .xpr files, and also modify generic model.
save_instance_accelerator = none : this is however another extreme decision. This mean .xpr files will never update or generate new, and if for some model they become outdated - they will stay outdated forever. hence reducing cases when they are used, since seriously outdated accelerator file is simply not used.
save_instance_accelerator = saved_objects* : this is default, and also recommended value. It means that if certain generic or instance model was modified and will anyway go to Save, such instances present in session will also update their accelerator files (or create new - if not existent). Hence keep up-to-date for further usage for speeding up assemblies retrieval. We expect that this setting should not make troubles in case of library parts, since if they are not modified they will not attempt to Save.