BoundingBox attributes vs boxextents - unexpected results

[AW_ME]

Having an issue with a calculated attribute on EPMDocument type to determine material thickness. Using attributes noted in CS324653 and using the supplied code for minimum model extent size  - the returned value  of the new attribute is not correct. 

As an example - when looking at the values in /servlet/odata/v3/CADDocumentMgmt/CADDocuments('{CADDocumentId}')/Representations for a sample part - the value for 'BoundingBox' is:
      "BoundingBox": [
        -0.0533878,
        -0.0673053,
        0,
        0.0860431,
        0.441427,
        0.009525
      ],
This data appears correct and are dimensions measured from the main part planes.

For this example - if Az is BoundingBox[2] and Bz is BoundingBox[5], then `BoundingBox[5] - BoundingBox[2] = 0.009525` which is correct for this part.

However, if I create a new calculated attribute on the CADDocument type (BoxThicknessmin), and set the formula equal to `abs(boxExtents.Az - boxExtents.Bz)`, the value I get for this new attribute is `"BoxThicknessmin": 0.014859520749434692` which is incorrect.

An incorrect valve is shown even if I make a direct attribute relationship without a formula (e.g. simply put BoxExtents.Bz as the formula). 

Does anyone have any suggestions or explanations on why the calculated value has an unexpected result? Are there any server logs that we could lookup to debug this issue?

[RandyJones]

As a warning the "bounding box" dimensions stored in Windchill are the useless size with datums:

Windchill PDMLink: Is it possible to show the value of EPMDocument boxExtents.* attributes without considering datums? 

[HelesicPetr]

Hi @AW_ME 

A value is stored In a database but this value can represent some Measurement System. The value is different for SI and for  USCS 

Check what is set in the model, and check what is really in the database and what is shown with the calculated attribute. 

Also check if the visualization is really actual and everything has been regenerated in the model.

Based on config the visualization is regenerated during visual process but user can forget to do so. 

PetrH

[PN_5076692]

Hi @HelesicPetr 

I'm trying to make use of the BoxExtents data as well.

Some of our models are in SI units, some use the USCS measurement (*sigh*) system.

Do you know if there is a way in WT to detect the measurement system for a given EPMDocument?

Regards

[RandyJones]

---

@PN_5076692 wrote:

Hi @HelesicPetr 

I'm trying to make use of the BoxExtents data as well.

Some of our models are in SI units, some use the USCS measurement (*sigh*) system.

Do you know if there is a way in WT to detect the measurement system for a given EPMDocument?

---

It does not matter what the model unit system is. The values are stored in Windchill as meters.

[PN_5076692]

Hi,

Thanks for the quick rep[y @RandyJones !

If that's the case, that would be great for our usecase! I was under the impression that the values changed after I changed model unit system.

But I'll check again 🙂

Thanks!

[PN_5076692]

Hello,

ok - I confirm: changing the model unit system doesn't effect the BoxExtents values. Great 🙂

The BoxExtent values / coordinates seem to "match" the size of the object but with some "error" / margin.

I made a box in Creo with these dimensions: 0.45m x 0.175m x 0.25m

If I use the BoxExtent coordinates to calculate the Box I get this: 0.456m x 0.181m x 0.256m

The calculated box seems to be 6mm wider than the model in Creo. i wonder why?

If I duplicate the size in Creo to 0.9m x 0.35m x 0.5m the calculated BoundingBox is 0.511m x 0.911m x 0.361m

Can anyone explain why the calculated box from the BoxExtents coordinates is bigger than the actual model?

Thanks in advance!

Regards

Philipp

[RandyJones]

---

@PN_5076692 wrote:

Hello,

ok - I confirm: changing the model unit system doesn't effect the BoxExtents values. Great 🙂

The BoxExtent values / coordinates seem to "match" the size of the object but with some "error" / margin.

I made a box in Creo with these dimensions: 0.45m x 0.175m x 0.25m

If I use the BoxExtent coordinates to calculate the Box I get this: 0.456m x 0.181m x 0.256m

The calculated box seems to be 6mm wider than the model in Creo. i wonder why?

If I duplicate the size in Creo to 0.9m x 0.35m x 0.5m the calculated BoundingBox is 0.511m x 0.911m x 0.361m

Can anyone explain why the calculated box from the BoxExtents coordinates is bigger than the actual model?

---

That is because PTC is using the useless size with datums per my previous post above.

Windchill PDMLink: Is it possible to show the value of EPMDocument boxExtents.* attributes without considering datums? 

[PN_5076692]

Hi@RandyJones 

ah yes. I saw that before, but I wasn't sure what exactly those mentioned "datum planes" were.
(I'm no Creo/CAD user, I just do some Java coding for WT 😉 )

So the BoxExtents would be great for getting BoundingBox data without additional parameters/WT attributes, but due the uinfluence of datum planes the data is no really usable. 😕

So we need to figure out a different way to get the relevant BoundingBox data from Creo to WT.

Thanks Randy!

Regards

Philipp

[PN_5076692]

Hello,

the solution seems is more simple than expected.

The BoundingBox information is available in the DerivedImage object / Represenation. The dimensions are always reported there in meters.

Regards

[AW_ME]

This is indirectly where I was reading the values originally via the API. The problem was when creating a calculated attribute using these values, the resulting value was incorrect. I was not able to determine the reason for the error, therefore the original problem remains unsolved.