Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations SDETERS on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Coordinate system in MBD 1

Status
Not open for further replies.

Woosang

Aerospace
Dec 18, 2009
48
Years ago, when my customer adopted MBD, its MBD construction guideline said that each MBD shall have a coordinate system and a datum reference frame as I recall, which sometimes made those useless for simple parts which do not need datum.

ASME Y14.41 Digital Product Definition Data Practice also says that a model shall have one or more coordinate system which corresponds to datum reference frame as paragraphs below (2012 version).

5.1.3 Coordinate Systems
A model shall contain one or more coordinate systems.
11.2.1 Datum Reference Frames and Coordinate Systems
The following requirements apply to the relationship between the datum reference frames on the model and the coordinate systems.
(a) Datum Reference Frame and Coordinate System Correspondence. Each datum reference frame shall be associated to a corresponding coordinate system.

I wonder why do they state such requirement, even when a product definition does not require any datum reference.
 
Replies continue below

Recommended for you

The logic in 14.41 is, IF there is a DRF THEN it must have a matching coordinate system; the inverse is not required.

You need to contact the manufacturer to clarify their requirement if you think it is not the same.
 
In MBD or RDD (the uses of Y14.41) the model represents the basic geometry, which means you don't display some of the basic dimensions on the 2D drawing or on the annotated model. Therefore there must be an ability to "query" the model (make measurements on the model). There is no way to make measurements if there is no coordinate system.

Hence, "A model shall contain one or more coordinate systems."

Personally, I never encountered a CAD model without a coordinate system.
 
The question was about the requirement for a DRF when the part had no datum features and therefore no datums.

 
The question was not about a requirement for a DRF but about the requirement for a coordinate system.
There is no requirement for a DRF in Y14.41.
 
"MBD shall have a coordinate system and a datum reference frame as I recall, which sometimes made those useless for simple parts which do not need datum.

"why do they (my customer) state such requirement, even when a product definition does not require any datum reference."

Every CAD model has a coordinate system; Y14.41 says each DRF should also have a coordinate system per DRF; the provided customer (not Y14.41) requirement is to have both even when one of them is not used by the model and for which, as the OP made clear, the model did not need a dataum.

 
I'm pretty sure that the question is why Y14.41 has in it the requirements that were mentioned.
 
"when my customer adopted MBD, its MBD construction guideline"

Those guidelines differ from Y14.41.

I believe you are pretty sure. Your confidence is not supported by the problem statement.
 
The way the question and the introduction to it were formed indicates that the question is not about an issue with that specific customer, but about general practices.

The customer is part of a background story/example that begins with "years ago...". The customer's MBD guideline "said..." (not says), etc. It all shows the OP is not concerned with a recent difficulty with that customer. Looks like the question is in the general context, and it's about MBD specs. The logic being communicated is this - if there are parts that can be geometrically defined without a DRF, why are there rules that require DRF-related coordinate systems? The nuance is that a coordinate system has other uses for MBD too - it's not only for DRF representation.
 
"if there are parts that can be geometrically defined without a DRF, why are there rules that require DRF-related coordinate systems?"

How is that a question? If there is no DRF there is no requirement for a CSYS related to the non-existent DRF. That Y14.41 rule does not have any other interpretation than in my initial response to the OP.
 
Woosang,

I am trying to avoid MBD. I have a note on my drawing that states that undimensioned features have a profile tolerance with respect to datums[ ]A, B, and[ ]C. What does a profile tolerance mean if there are not datums?

--
JHG
 
JHG,

Better question, why create a CSYS at all for any DRF? All datum features would already be identified/labeled.

Supposing a flat sheet metal part - one flat face is datum feature A. There should be no need to create a datum plane as the feature itself is sufficient, but who cares if all features of the part refer to A? There is no CSYS required or usable.

A CSYS doesn't capture priority either. Maybe this is for CMM software guys who don't want the effort of writing a DRF parser?
 
3D said:
"if there are parts that can be geometrically defined without a DRF, why are there rules that require DRF-related coordinate systems?"

How is that a question? If there is no DRF there is no requirement for a CSYS related to the non-existent DRF

The question originates from an assumption that the quoted requirements (the segment from 5.1.3 and 11.2.1) are only to support datum reference frame representation. While it is true for 11.2.1, for 5.1.3 it is not so. If you don't remember the use I mentioned, you might not understand why 5.1.3 is there. 11.2.1 is obviously irrelevant for product definitions that don't specify a DRF.
 
3D said:
Maybe this is for CMM software guys who don't want the effort of writing a DRF parser?

The main drive for MBD is machine-readability and allowing automation. The impact on CMM operation possibilities is a legitimate consideration.
 
Also if you use the model only to inspect the part manually you may want to be able to make easy queries from the datum on the model. A coordinate system sitting on the datum feature allows that.
 
"Also if you use the model only to inspect the part manually you may want to be able to make easy queries from the datum on the model. A coordinate system sitting on the datum feature allows that."

It is only associated, not coincident and not apparently required to be unique. All DRFs could refer to different datums and be associated with a single CSYS.

The CMM alignment is from the surfaces, not the CSYS, so the CSYS appears to add no useful information.

It is fundamental and inescapable that every CAD model has a base coordinate system. There have been no CAD modelers that do not have one. XY for 2D and XYZ for 3D.

Thanks for B-splaining your limited CAD understanding. Are you using Chat-GPT?
 
3D,
Apparently you lack the experience it takes to start appreciating a proper relationship between a model and the main axis system that sets the coordinate directions for queries, or a properly placed local axis system, for both design and inspection.

When you expect automation of PMI usage, models that answer standardization requirements become even more important.
Recently there was a thread here on MBD where issues with annotated models that prevent achieving the wanted MBD/MBE advantages were brought up. From my experience, it often results from engineers preparing the models wrong, because of the exact same ignorance you are displaying now.
 
ChatGPT works pretty well, but you need better prompts.

All CAD systems already have coordinate systems. The initial CSYS is not optional and requires no input from the user to create; they are intrinsic. As soon as the NEW button is clicked and the name entered and then OK - that is when the first CSYS is created for the item. Can't avoid it, cannot delete it. Any measurement done at that point is done in that coordinate system.

Y14.41 originally failed to standardize function - it was a sales tool for CAD companies to claim compliance without providing uniformity of user interface or guarantee of interchangeability. It spent some effort on appearance, but the result reminds me of Applicon Bravo! view cells. That was available from Schlumberger.

We used ComputerVision's CADDS III and CADDS IV, a smattering of Cadra from Adra on custom CADRA workstations; this was before Apple released the Macintosh. Manufacturing liked UG II; we transferred wireframes for them to create tool paths until they got screwed over and it was replaced with Mazak and the Mazatrol software that they did not buy any import software for. I later picked Pro/E and it was pretty quick to ditch wireframes and the CSG modeler in Bravo! (Still have the MAGi Synthavision (used to create the original Tron movie) cheat sheet around someplace - found out how to debug a problem that Applicon had in generating the FORTRAN card image input to get results we wanted.)

The most fun was a short detour to Mechanical Advantage - a 2D constraints solver that wasn't order dependent. It had the best underconstraint hinting. It ran on a MicroVAX with DEC Ultrix and included the full C compiler, so I could transfer data over DECnet to the 11/750 1/2 tape drive and then to the tape drive on the ComputerVision NOVA, which was essentially dedicated to CADDS IV. C- Size tablet for command shortcuts or digitizing data. A long way as Mechanical advantage only did bit-map screen shots for output and did not handle 3D.

DEC Ultrix was the intro to UNIX and the first Pro/E stations were HP-UX; also with a C- compiler. AWK and grep were also very helpful.

[Recall when Ken Olsen at DEC declared that VMS would win and called UNIX snake oil? How's that working out? Sure, the VMS architect went to Microsoft and developed Windows NT, so sort of VMS is still around but so is the UNIX offshoot Linux and I think more hardware runs that now than runs Windows; Android is based on Linux and Apple's iOS is BSD UNIX based.]

In the middle of that I drafted a list of about 100-150 features ComputerVision (CV) could add, such as making the parameters to T-CYLS available, with little change to the core product; I had tired of putting in all the dimensions only to place views and then repeat the work of placing the dimensions again. Seemed like making the model store that information would be a time saver. About 2 years later PTC made their software public, but it was another 2 years before they created the drawing module. CVs response was a series of really poor solid modelers; PTC eventually bought CV, gaining the now Windchill PDM product.

I picked Pro/E as the company replacement for the variety of tools that had accumulated and it was pretty quick to ditch wireframe/surface modeler and the CSG solid modeler in Bravo! I think we ended up with 30-40 licenses of Pro/E.

Then about 30 years of using Pro/E mixed in with more C programming to generate shapes the CAD tools were too slow to do. There was also a year's stint with using VSA software from Variation Systems to perform assembly level variation tolerance analysis. VSA got sold and the guys who trained me from there got very rich after several years of 80 hour weeks, developing marketing and consulting. It looks like the tool 3DCS sells as Variation Analyst; somewhat confusing is a similar package called Tecnomatix® Variation Analysis software (VSA) but we dropped the analysis as it really depends on getting variation distributions back from manufacturing to predict yield and the QA team wouldn't tell anyone more than PASS/FAIL.

We also looked at and took a pass on CE-TOL, the product that Kenneth Chase developed at BYU in some relation to TI, who sold it as TI-TOL; Sigmetrix now sells CE-TOL and BYU eliminated all public facing record of Chase and the AD-CATS program. As much as the vector loop method appeals to probability mathematicians, it didn't handle non-orthogonal variation because it depended on PTC's model regeneration system to determine sensitivities. At no time could a lack of feature parallelism enter the loop because the model surfaces remained perfectly parallel. CE-TOL has no doubt been improved since then but at the time it was not great. Of course PTC bent over backwards to integrate it; it did 30% of the capability of VSA and cost about 50% of the price.

To go along with the Synthavision cheat sheet I have the Renderman reference guide I bought from a then small company named Pixar. I also got the VHS tape with Knick-knack and Tin Toy from them. Those tapes went to the computer club. My hope was that PTC would license Renderman as a replacement for their crummy renderer, but I got decent results out of POV-Ray instead. Keyshot took the CAD world lead on rendering, and do a great job, but they are expensive. Later when PTC acted as if being open was an advantage they yet again blew past a chance, the second time skipping modest integration with Blender. PTC later had another renderer, but I recall nothing outstanding about it. Blender should have been the better choice.

I doubt you have any real questions and were just tossing ignorant crap around but CAD has interested me since a demo I saw around 1967 on the IBM/360 machine my father was a software systems analyst for, just a faceted wire frame facemask that turned a bit.

Any suggestions about what I might lack in understanding the full stack from CPU machine instructions from RISC to CISC to VLWI** and the current hybrids to the development of Open/GL by SGI (got an IRIX to play with for a few weeks - great demos of radiosity and rubber-like properties in interactive applications, but too costly) and the DirectX response from Microsoft - anyway - sniffle your way to a tissue for all that runny nose trash talk.

** Speaking of which the massive parallel Transputer - that was a hoot.
 
Before you guys are killing each other (like you are usually doing) I would ask the OP:

Woosang,
What do you mean by "THEY" ?
Who are THEY?

OP said:
....why do they state such requirement.....


I fully understand that sometimes (more often than not) the language is a barrier, but could you please clarify?

Those guys are willing to get nuclear on each other, so your clarification is a MUST (if you really want an answer and not came here to troll the forum)
By the way, that’s exactly why GD&T has been “invented” because, clearly, words are failing us. We cannot be clear in our verbiage…..sad, but true.

 
3D,
While your standards knowledge and programming experience are impressive, do you have any actual working experience on a full MBD program (no drawings)[ponder]

"Know the rules well, so you can break them effectively."
-Dalai Lama XIV
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor