Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X
The light gray text is lighter than previous versions of cero and is causing me eye strain to read it.
52 Views and NO replies. Doesn't anyone have an opinion on this topic?
Generally, that's something we work hard to avoid, and generally when it happens, we act to fix it so that the old feature regenerates the old way. The situation you describe is certainly not the norm. To comment further, I'd need to know about the circumstances, perhaps you could send me info on the SPR # and the option name?
Case# 13450674, SPR# 6352654, hidden config option "upd_mtraj_sweep_pat_crflg" value "yes"
Thanks
I can see why a customer may want it to fail..so they can fix the model properly with the newer tools in a newer release. Not ideal by any means, and the hidden config option allows the model to load and regenerate using the older code. PTC obviously had some reason for changing the code, they just didn't 'proof' it well enough to take into all issues that require updating internally.
All right, here's the answer. It's a wee bit complicated... The TLDR form is: fixing it in all streams in the next build.
In WF5 M130, we implemented some code for how we manage backup information for pattern member features that employ a section. We do this only for new features, to avoid changing existing ones on retrieval.
In Creo 2, we got an SPR, and investigating, found that in the specific case of patterns of multitrajectory sweeps, we should not use this new code. So we made a second change, in Creo 2 M120, to exclude the multitrajectory sweep pattern members from it, again only for new features.
Later in Creo 2, we got a third SPR on a related topic -- this new backup information code was slightly incomplete. This was fixed, but without the necessary versioning check, so it applied to old features as well. This was done in Creo 2 M180. The application of this change to most features seems to have been harmless, but in the case of post-WF5-M130, pre-Creo2-M120 multitrajectory sweep patterns, which shouldn't be using this code at all but were to preserve their old behavior, it could cause the feature to fail where previously it regenerated.
Later (Nov 2015), an SPR was reported noticing this fact. The programmer, presumably busy with a dozen tasks, noted that it could be fixed by flipping the versioning switch from M120, and this was satisfactory to the customer, so they provided a mechanism to do so (the hidden config) in Creo 2 M220. Ideally, they would have said 'while I can patch the data, I can tell this represents a failure to preserve upward compatibility for feature regeneration, and should investigate further', but ideally, we'd have more people doing the work.
A year and a bit later, Wayne enters the story, having encountered the same issue, and files an SPR. The developer investigating notes the cleanup mechanism from M220 gets the job done, and resolves the SPR against that. Wayne however rightly notes that this is an upward compatibility issue, and such things should generally not just be patched.
Last, I read Wayne's post, and agree that it sounds fishy, and do some digging, eventually figuring out the chain of events above. I get everyone's OK to fix it up, and make a fix for: Creo 2 M250, Creo 3 M130, Creo 4 M020, Creo 5 F000, implementing post-facto versioning for the previously-unversioned Creo 2 M180 change, so that models retrieved from older builds will behave as they did the build in which they were previously saved. (And various people are reminded of the importance of upward compatibility and being vigilant about versioning.)
Thus ends the story.