Serious Wildfire 5 M160 family table and workspace synchronization issues

[RandyJones]

PDMLink 9.1 M070
Wildfire 5.0 M160

We have discovered the following 2 issues with Wildfire 5 M160 and PDMLink 9.1 M070.

Issue 1:
After modification by Pro/Engineer Wildfire 5.0 M160 and checkin to PDMLink 9.1 M070 family table
controlled angle dimensions are incorrect when opened in previous builds of WF5 and Creo 2.0 M020.
This is reproducible as follows:

1. using Wildfire 5 M150 (or earlier build) checkin family table that includes angle dimensions
2. using Wildfire 5 M160 modify and checkin this family table
3. using Wildfire 5 M150 (or earlier build or Creo2.0 M020) open the family table version created
    by WF5 M160
4. note the family table controlled angle dimensions are now incorrect (ie what should be 30 is 0.78)

Issue 2:
Under certain circumstances Pro/Engineer Wildfire 5.0 M160 exits attempting to Synchronize the
workspace. This happens after renaming components in Windchill and then attempting the Synchronize
the workspace. It doesn't crash with every rename/synchronization but when it does happen there are
only 2 ways to synchronize the workspace. You can fire up Pro/Engineer M150 (or earlier) to
synchronize or delete/rename the local workspace cache and register the Windchill server.


I have calls open to PTC on both of these issues with spr 2157859 for issue 1 and spr 2157091 for
issue 2.

In my opinion issue 1 is a very serious issue because users on earlier builds of WF5 or Creo 2.0
have incorrect geometry when opening these WF5 M160 modified family tables. The combination of the 2
issue is very bad because you have this:
1. WF5 M160 crashing when synchronizing workspaces
or
2. going back to WF5 M150 and getting incorrect family tabled parts


Has anybody else experienced these 2 issues with WF5 M160?

--

[JoshuaHouser]

Hi Randy,

First, thanks for posting the warning! I completely agree that family table values changing is a very serious issue.

I'm wondering if you've had a chance to verify that Windchill plays a role in the Family Table issue with WF 5 M160? Maybe do a backup of the family table to a local drive from an earlier build and then open with M160?

I'll post here if I find anything.

Joshua Houser| Pelco by Schneider Electric |Buildings & Business| United States| Methods & Tools Sr. Engineer
Phone: +559-292-1981 ext. 3490| Toll Free: +800-289-9100 ext. 3490&nbs

[RandyJones]

On 11/26/12 12:37, Joshua Houser wrote:
>
> Hi Randy,
>
> First, thanks for posting the warning!  I completely agree that family table values changing is a very serious issue.
>
> I'm wondering if you've had a chance to verify that Windchill plays a role in the Family Table issue with WF 5 M160?
>

Windchill has to be in the mix for this to happen. This is not a problem with unlinked sessions of Wildfire 5.

>  Maybe do a backup of the family table to a local drive from an earlier build and then open with M160?
>

If you do the following:

1. add to workspace a WF5 M160 modified/checkedin family table
2. from the local workspace cache copy the wfcont file
3. open the file in WF5 (any build) or Creo 2.0 M020
4. the family table values are correct

So opening with a "linked to Windchill workspace session" the values are incorrect in WF5 M150 (or earlier) and Creo2.0 M020. Opening (in unlinked session) the same file (copied wfcont file), as snarfed from the local workspace, results in correct family table values.

Windchill == broken
NonWindchill == okay

> I'll post here if I find anything.
>
> *Joshua Houser*  | *Pelco by Schneider Electric   | Buildings & Business*  | *United States*  | *Methods & Tools Sr. Engineer*
> *Phone:*+559-292-1981 ext. 3490  | *Toll Free:*+800-289-9100 ext. 3490&nbs
>
>
> ----------


--

[AdamDorsch]

Production system: Windchill PDMLink 10.0 M030 with WF5 M130

Test 1: In the test system created new family table with a length, diameter and angle dimensions changing in the table. Saved and checked in. Since my systems are separate I had to then export the new part from my workspace. Then I went into our production system and opened the file. The length and diameters were fine but the angles went from 10, 20, 30, 40, and 50 to .175, .349, .524, .698 and .873

Test 2: In the test system created a new family table with length, diameter and angle dimension. I did not check this one in, just exported. I then opened this in production and the same problem. The length and diameters were fine but the angles were changed to .175, .349, .524 and .698 (from 10, 20, 30 and 40).

It appears to be a M160 issue and not so much tied to the Windchill datecode I guess is what I am seeing.

Glad this was mentioned, I would have never caught this error otherwise and we would have gone headlong into the upgrade this weekend.

Adam Dorsch

[RandyJones]

On 11/27/12 07:05, Adam Dorsch wrote:
>
> I was able to duplicate this on our system as well as we are working towards a PDMLink 10 M040 and
> WF5 M160 upgrade. While I cannot test exactly as described I was able to replicate the error.
>

Good. Please open a call with PTC.
According to PTC tech support we are the only customers (as of yesterday) that have reported this issue.

> Production system: Windchill PDMLink 10.0 M030 with WF5 M130
>
> Test system: Windchill PDMLink 10.0 M040 with WF5 M160
>
> Test 1: In the test system created new family table with a length, diameter and angle dimensions
> changing in the table. Saved and checked in. Since my systems are separate I had to then export
> the new part from my workspace. Then I went into our production system and opened the file. The
> length and diameters were fine but the angles went from 10, 20, 30, 40, and 50 to .175, .349,
> .524, .698 and .873
>
> Test 2: In the test system created a new family table with length, diameter and angle dimension. I
> did not check this one in, just exported. I then opened this in production and the same problem.
> The length and diameters were fine but the angles were changed to .175, .349, .524 and .698 (from
> 10, 20, 30 and 40).
>
> It appears to be a M160 issue and not so much tied to the Windchill datecode I guess is what I am
> seeing.
>
> Glad this was mentioned, I would have never caught this error otherwise and we would have gone
> headlong into the upgrade this weekend.
>
> Adam Dorsch
>
>
> ----------


--

[LawrenceS]

This is frustrating. When will PTC tech support realize that just because only one customer reports an issue it does not mean that only one customer is having the issue? Not everyone will be able to find the cause and repeat an error, or take the time to report it.

If the problem is repeatablePTC should take the opportunity to improve their product by fixing the issuefor everyone (especially when serious, like this one). Randy, thanks for bringing this problem to the forums!

Lawrence

In Reply to Randy Jones:

[RandyJones]

On 11/27/12 11:22, Lawrence Scheeler wrote:
>
> This is frustrating.  When will PTC tech support realize that just because only one customer
> reports an issue it does not mean that only one customer is having the issue?  Not everyone will
> be able to find the cause and repeat an error, or take the time to report it.
>
> If the problem is repeatable PTC should take the opportunity to improve their product by fixing
> the issue for everyone (especially when serious, like this one).
>

I forgot to mention this in my first post however PTC has reproduced both of these issues.
The family table issue has a Top priority SPR and the workspace synchronization issue has a High
priority SPR. So they are taking this seriously.

> Randy, thanks for bringing this problem to the forums!
>
> Lawrence
>
>
> In Reply to Randy Jones:
>
>     On 11/27/12 07:05, Adam Dorsch wrote:
>     >
>     > I was able to duplicate this on our system as well as we are working towards a PDMLink 10
>     M040 and
>     > WF5 M160 upgrade. While I cannot test exactly as described I was able to replicate the error.
>     >
>
>     Good. Please open a call with PTC.
>     According to PTC tech support we are the only customers (as of yesterday) that have reported
>     this issue.
>
>
> ----------


--

[AdamDorsch]

I opened a help ticket with PTC yesterday morning and never heard back from them. Very frustrated at this point.

I referenced Randy's SPR in my ticket to try and make sure they realize more than onecustomer is experiencing this issue.

Edit: They finally responded

"This is regarding case #11134983 with description "Testing WF5 M160 and encountered an error with opening a family table in an older datecode. Another company encountered this and opened SPR 2157859 for the issue."

I apalogize for not contacting you on this call yesterday, we are in the process of making this SPR a top priority. I will let you know for the any info from R&D."

[RandyJones]

I have "discovered" some more interesting info about these 2 issues.

Issue 2: Under certain circumstances Pro/Engineer Wildfire 5.0 M160 exits attempting to Synchronize the workspace.

      o A workaround (that works most of the time) is to select the objects that need Synchronization and the select "Tools | Synchronize"
          + This was discovered by one of the users at work.
          + Usual practice is to not have any objects selected when doing "Tools | Synchronize"

Issue 1: Wildfire 5 M160 family table angle dimension issue

  * Given the following steps

1. in WF5 M160 open "pre WF5 M160" family table
      * all angle dimensions are correct
      * angle1 = 60.00
      * angle2 = 10.00
2. modify the table and checkin or upload
3. exit WF5 M160
4. start WF5 M150 and open the family table
      * angle1 = 1.05 (incorrect)
      * angle2 = 0.17 (incorrect)
5. modify angle2 back to 10
      * don't change angle1 leave it at the 1.05 value
6. upload or checkin
7. exit WF5 M150
8. start WF5 M160 and open the family table
      * angle1 = 60.00 (correct)
      * angle2 = 572.86 (incorrect)
9. exit WF5 M160
10. start WF5 M150 and open the family table
      * angle1 = 1.05 (incorrect)
      * angle2 = 10.00 (correct)
11. Now I am starting to see what is happening after modification by WF5 M160...
      * WF5 M160 sees the values as radians and converts to degrees
          o that is why angle2 in step 8 shows as 572.86
      * WF5 M150 sees the radian values but does not convert to degrees
          o that is why angle1 is now showing at 1.05

So in conclusion we have this:

  * Opening a "pre WF5 M160" family table in WF5 M160 for the first time all angle values are correct
  * Modify this table in WF5 M160 and checkin/upload
  * Reopen the table in WF5 M160 all angle values are correct
  * Open the table in WF5 M150 (or earlier build, or Creo 2.0 M020) all angle values are incorrect (off by a factor of pi/180))
  * Modify an angle dimension in WF5 M150 and checkin/upload
  * reopen the family table in WF5 M150 and "modified by WF5 M150" angle dims are correct. "modified by WF5 M160" angle dims are incorrect (off by a factor of pi/180)
  * open the family table in WF5 M160 and "modified by WF5 M160" angle dims are correct. "modified by WF5 M150" angle dims are incorrect (off by a factor of 180/pi)

Are we having fun yet...

[AdamDorsch]

Wow, what a mess. Other than that e-mail from yesterday morningI haven't heard anything from PTC. At this point we are delaying our upgrade till the end of the year and going to reset our test system with Windchill PDMLink 10.0 m040 with WF5 M130 (our current datecode).

Adam

[RandyJones]

Some more information on these issues.

Issue 1: Wildfire 5 M160 family table angle dimension issue

* PTC has issued document CS80612
o PTC Tech support told me to try this.
o I have verified this fixes the crash on both Solaris and Windows platform.
o My startup scripts now have UWGM_FIX_PDM_ATTRIBUTES set to "off"
* Here is the email I rec'd back from PTC Tech support explaining what setting UWGM_FIX_PDM_ATTRIBUTES to "off" doe...

[RandyJones]

PTC has issued document CS104046 https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS104046