Bryce Gill

Flat pattern view doesn't match model

Discussion created by Bryce Gill on Feb 24, 2020

I've had this issue recurring for several years now, and haven't had any luck finding a resolution through my VAR. In summary, occasionally a sheet metal flat pattern view will have a visual display that doesn't match the actual part geometry. It appears that it's from an old configuration, as sometimes for example holes are moved or different sizes. An example of this bug is attached.

 

Error shown: the two holes on the base of the part are shown as a different size and position when the part is selected. The blue (or orange if selected directly) geometry is correct, and represents the actual part. Any dimensions or other references to the part geometry will correctly reflect the location of the holes shown as selected. Measurements, evaluations and selections done through the API also reflect the correct geometry. However, it is only shown on selection and saving this view to a DXF carries the black/incorrect geometry forward. 

 

Error hidden: part shown unselected. The black holes cannot be selected directly - if I attempt to do so, the orange hightlight/selection circle appears where the correct blue geometry is in the first image.

 

Error resolved: issue is resolved after toggling the view's configuration from the flat pattern and back again.

 

This presents a problem for my manufacturing downstream, because the part is saved to a .DXF from the flat pattern view and the DXF file now represents the incorrect geometry. Much of my production drawing checking and formatting is done via automation, and I haven't been able to find a way to check for this bug using the API. It's usually simple to fix the issue when it is discovered, and can be done in several ways - opening the part and rebuilding/resaving the flat configuration usually works, toggling the configuration of the bad drawing view to another and back again, or if all else fails deleting the offending view (and children) and remaking it. Simply rebuilding the drawing doesn't work without one of those steps, and it's not predictable which of those steps will fix the issue.

 

This bug has cost my company money in rework and engineering time and will continue to do so until we can find away to prevent it or automate the fix. I'm hoping to get some insight to this issue in three regards:

 

1. Has anybody seen this before? My VAR hasn't been able to help on the issue, especially since I can't reliably reproduce it and neither can they.

 

2. Is there a way to detect this issue through the API?

 

3. Is there any way to prevent the issue from happening in the first place? It has so far cropped up unpredictably, having been discovered on parts that were created through automation as well as through manual work on different machines and by different users. 

Outcomes