Needed Devlopments in Constraints

[JST]

Yep, that type constraint is what I want. Call it "approximate", or "proximity" ("proximal"?), or whatever...... One where if it falls in the "window" it is considered to be able to be aligned.

I think it may be most similar to the "tangent inside" constraint, and that actually might be able to be used.

As I think about it, a possible workaround is to put a pin of the desired size into the hole. Then constrain the pin using a tangent inside. Constrain the other part to the pin using the same condition.

Theoretically, the two can be satisfied at once. I do not know if Alibre WILL do that, it can be fussy and petulantly ask for clarification, wanting you to move the parts closer to the desired alignment.

Also, that may not allow the part to be parallel to another part, even if the alignment could work, because with the tangent inside, the holes and pin HAVE TO touch. With a true "proximal constraint", the pin could be anywhere within the area, even if the surfaces do not touch or align, and the hole centers can be anywhere within a range around true coincidence.

 

[Lew_Merrick]

What I am hearing here seems to me to be a lack of using Global Variables ans Equation Editor values to coordinate things than anything else! First of all, they are not "Parameters" as parameter is an historically defined mathematical term that does not apply to this usage. Secondly, the term "Global" is a poor choice (at best) -- they are "Projet"-wide in this usage. Getting the concepts properly defined is the first step on the road to using them correctly!

 

[JST]

What I am hearing here seems to me to be a lack of using Global Variables ans Equation Editor values to coordinate things than anything else! First of all, they are not "Parameters" as parameter is an historically defined mathematical term that does not apply to this usage. Secondly, the term "Global" is a poor choice (at best) -- they are "Projet"-wide in this usage. Getting the concepts properly defined is the first step on the road to using them correctly!

Clarify?

Because it seems that the true issue is with the precision required by Alibre to allow a constraint, vs the capability of the math routines to PRODUCE that level of precision.

And secondarily that the "coincidence detection" is not co-ordinated with the displayed and enter-able number of decimal places, so that two distances between holes that display as the same number, are not actually able to be constrained together.

Plus, tertially, something within Alibre seems to change numbers even when they ARE entered, so that 4.000000 can end up being displayed as 3.999999 instead.

I am not clear how using global variables can affect any of those.

 

[Lew_Merrick]

JST -- If you need to control a fit between two Parts, then Project Variables is the answer. Let's say I have a Part with s MMC dimension of 4.000 inches that must fit within a "slot" in a meting Part with s nominal Slip Fit of (say) .002 inches of clearance on each "side." I define my Prokectt Variables as (say) "Tounge_MMC" and assign it a value of 4.000 inches. and as "Tounge_Side_Clearance" and assign it a vlue of .002 inches. Now, assigning my Project Variable of Tounge_MMC to the width in Part 1 and a value of Tounge_MMC + 2*Toung_Side_Clearance to the mating "Slot" in Part 2 gets me there and allows me. through standard editing techniques, to change either the Tounge Width or Tounge Side Clearance quickly, easily, and reliably.

 

[JST]

Ah, well the problem comes when you have no idea what the dimension will be. It's not a design variable, it is something that "turns out" to be a distance, based on reasonable dimensions for the anchoring flanges and hole locations.

You have a steel frame, which will have X bracing, with bolted joints at the ends. You put the pieces together and measure the "X" distances, which come out to be, say, 15feet and some amount of inches out to 6 decimal places.

Fine... you input that as the distance between holes, using 6 decimal places. You then "install" the brace. aligning first the hole at one end, then the hole at the other....... Only the second one will NOT align.... So you measure..... looks good...... but it throws an error, and will not align.

SOMEWHERE you have to "cheat".

Either you make the anchor flanges not actually to dimension, but just the slight amount "off" to fit, using a "project to sketch" approach, or you just lay it in position close enough, verify it looks aligned, anchor the part, and go on....

If there are two braces, and as usual they are "tied" in the middle, they should be OK, the error is actually tiny. You know it WILL fit, even though Alibre will NOT allow it to actually align as a constraint.

Such is steel work.

 

[Lew_Merrick]

JST -- Have you ever heard of Maximum Material Condition (MMC) or Least Material Condition (LMC) analysis? Can you perform either? Have you read (or understood) ANSI Y14.100?

 

[oldfox]

As you found out, Thompson and I are not just blowing smoke.

I hope you weren't meaning that I was trying to insinuate that. I really, really wasn't. It was just an observation.

I found out what it was..... The problem in THIS case was that I had set a distance to 4.000000 mm. When I checked the dimension, I got 3.999999 mm. And a 5.000000mm dimension actually showed up as 5.000001 mm.

The issue goes back to the dawn of computing and has never really gone away.

I have seen this in AD on many occasions where the sum of the 2 bogus numbers equaled the overall sum of the 2 dimensions *exactly*.
One scenario that comes to mind would be bit wobble in one of the numbers, so somewhere in the software it makes up for it
by changing the other dimension. Yeah, I know, sounds kinda far fetched but in my previous working career, I saw bit wobble come
about on a fairly regular basis. Back then with the technology what it was, (not nano yet) bit wobble could be overlooked.

Again, just my thoughts.

 

[JST]

Yes, I have seen cases where the sum is still correct. And others where the sum is not correct.

In any case, the "changes" are enough to make alignments fail. I think I have seen cases where once-good alignments fail due to just that sort of internal number change.

JST -- Have you ever heard of Maximum Material Condition (MMC) or Least Material Condition (LMC) analysis? Can you perform either? Have you read (or understood) ANSI Y14.100?

Yes I have "heard of" them, and understand what they mean. I am not so sure that the programmers do.

No it does not really apply to the situation, which originates in the math inside Alibre. And applying it to steelwork is almost funny.... Applying to machined parts is another issue entirely. In any case, this is not design, it is "detailing", a bit different situation, translating the general description into actual parts with dimensions.

To assemble steel, you have several spud wrenches.... into one hole goes the "spud" on one wrench. It gets pounded etc in to "draw" the holes in the two pieces until the next hole is aligned. Bolt goes in that next hole, and gets light snug (or snugged tight if you are confident). Out comes the wrench, and in goes a bolt.

It is basically EXPECTED that things will not completely align, which is one reason every bolt hole is made 1/16" over for the common small bolts. Machine shop tolerances are not applicable. The assemblies are metres long, and may have been laid out with a tape. The steel is not made to precise thickness. Angle clips are not perfect right angles, etc, etc, etc.

Re-read the explanation of the problem. Take a look at the 20 metre long assembly I posted a picture of, and imagine the magnitude of the error if various holes are fractionally out of position, and steel is of different thicknesses, etc. Add-in diagonal bracing, and what you have at the end is a big compromise, that is just sloppy enough to generally work.

I am pretty sure you know all this......

 

[Lew_Merrick]

Yes, I have seen cases where the sum is still correct. And others where the sum is not correct.

I find your arguments specious and ignorant of standard design techniques. You design to fit and then provide tolerances and allowances to ensure that they do. It is really that simple.

 

[bigseb]

You design to fit and then provide tolerances and allowances to ensure that they do. It is really that simple.

This right here is the gospel

Lew, I believe JST's issue is that, due to rounding, the holes do not align when in positioning them in an assembly. You are of course correct that

You design to fit and then provide tolerances and allowances to ensure that they do

and there are other ways to align the parts they design but the rounding error prevails.

 

[Lew_Merrick]

Lew, I believe JST's issue is that, due to rounding, the holes do not align when in positioning them in an assembly. You are of course correct that and there are other ways to align the parts they design but the rounding error prevails.

Then, by definition, he is not using the correct Assembly Constraints. Until he learns to do so, he will have "problems" in this regard!

 

[bigseb]

And I have the solution:



*DRUMROLL*

I figured that since this is a rounding issue the solution would lie not in calculating the new distance but rather using variables in calculations to determine the lengths. This cuts out any and all rounding errors.

See that attached package. It uses a global variable file to do the necessary maths. Note the following Variables:
X001 = Brace 1 Length
X002 = Brace 2 Length
X006 = Brace 3 Length
Brace three has, to my understanding, been the troublesome one due to the aforementioned rounding. By using the global variable file and entering the required sizes for X001 and X002 it will calculate the correct distance for X006 without rounding.



The attached package is for right angled triangles. Feel free to modify as needed.

Now... bow and kiss the ring...

 

[JST]

First....

Lew mentions tolerances. I will remind him that Alibre makes no allowance for tolerances. In most any CAD program, everything is exact, to the millionth of a "unit", with no tolerance accepted.

I will also remind Lew that what I am suggesting, is a way to actually EMPLOY "tolerances" within Alibre, to verify that parts will fit when a certain location tolerance is allowed when fitting the parts together.

It is of no particular service to the client or the shop if the theoretically precise number is used. The shop will lay out the steel to 1/32". Maybe some shops will go to 1/64". In my experience, steel shops so not deal with 1/64", and are not fond of 1/32".

Using those increments will inevitably introduce some errors. Distances to 1/32" increments do not express the real distances precisely. Nor do 1/64" increments.

What is wanted is a way to assemble parts modeled to shop dimensions, and check them for fit. The only means available are constraints. So a constraint that has a range within which it does not throw an error is what is wanted. If a new constraint causes a previous constraint to be forced beyond its tolerance range, THEN it will throw an error.

It seems pretty simple.....

Second.... Alibre and dimensions:

One measures a dimension, and puts the resulting distance in as the distance between holes. That should work since Alibre says that is the distance, and you put that same number in AS the distance in a mating part.

Then, one finds that the measured distance, when put in as the distance between holes in the mating part, DOES NOT ALLOW THAT PART TO ALIGN, according to Alibre.

So, you measure the distances between holes om the part, and on the assembly. It is the same on the part and the rest of the assembly to six decimals. NO DIFFERENCE. But Alibre insists that these are actually two DIFFERENT distances, while DISPLAYING them as the SAME.

Lew is BLAMING ME for this difference. I find that flabbergasting. He suggests that if I "learn" something, that magically Alibre will stop insisting that two distances which Alibre displays as the same, are actually different.

Now, when what I "learn" affects the result of what should be a mathematical equality, I think there will be some sort of serious problem.

Suppose I calculate all the distances myself, come up with the distance between holes (the same distance that Alibre says it is), and now I just input the numbers that I calculate (same number as before)....... Do you REALLY suppose that the SOURCE METHODOLOGY will affect how Alibre interprets that SAME number?

I put it to you that such a thought is ridiculous on the face of it.

Alternately, if I calculate the number, and find that it is DIFFERENT from what Alibre displays as a measurement...... do we suppose that if I input that DIFFERENT number, that Alibre will magically accept the DIFFERENT number as being actually the SAME as a measured number which it displays differently?

No, we can discount what Lew is saying. He is way off the point.

If Alibre says a distance is 243.125000 inches, and I type in 243.125000 inches, I expect Alibre to agree that those two are equal.

Lew apparently does not think that is a reasonable expectation.

Lew is really suggesting a "mind over matter" situation here, where the same number will act differently depending on how I arrive at the number. Apparently he is suggesting that my "attitude toward that number" will affect how it is used by Alibre. "New Age" engineering, I suppose.

I also expect that if I type in that number, that it will remain the same, and not be changed. Lew (and the Alibre programmers) seem to think it is quite OK if that number gets "adjusted" from what I typed in.

 

[Thompson]

JST -- If you need to control a fit between two Parts, then Project Variables is the answer. Let's say I have a Part with s MMC dimension of 4.000 inches that must fit within a "slot" in a meting Part with s nominal Slip Fit of (say) .002 inches of clearance on each "side." I define my Prokectt Variables as (say) "Tounge_MMC" and assign it a value of 4.000 inches. and as "Tounge_Side_Clearance" and assign it a vlue of .002 inches. Now, assigning my Project Variable of Tounge_MMC to the width in Part 1 and a value of Tounge_MMC + 2*Toung_Side_Clearance to the mating "Slot" in Part 2 gets me there and allows me. through standard editing techniques, to change either the Tounge Width or Tounge Side Clearance quickly, easily, and reliably.

Well, that's fine, but JST really wasn't talking about controlling the fit between two parts. He was talking about constraining the model so it wouldn't explode. Absolutely completely different things. On occasion I've longed for a "rubber band" mate but have always been able to cheat it enough to get what I needed. I suspect that a model with several "approximate" mates would be too computationally expensive to make it worthwhile. MMC & LMC and tolerances really have nothing to do with this particular feature.

 

[JST]

Exactly.

That sort of case, or the cases of the apparently identical distances that Alibre thinks are different. It allows you to make the model, WITHIN YOUR SELECTED RULES, and go on, without resorting to a "by eye" alignment as a check, with an "anchor" to keep things under control.

As mentioned, the "rubber band mate" or "tolerant constraint" is relatively similar to a tangent constraint. Much of the time those will adjust within their range of allowed motion when another mate or align to a tangent constrained part is made, or, even more often, when you already have an align, and you then make a tangent constraint. Alibre usually finds the way that works, or can be helped to.

Where you would get into trouble is with a string of such constraints. Now your program has to try each one and come up with a multi-way compromise. That is unrealistic in my opinion. As it is, you get the instruction to "move the parts closer to the desired condition", which usually works.

Where the "rubber band mate" or "tolerant constraint" shines is in the situation of the 1/32" increments, where something such as a diagonal will not align with "exact" constraints, but is close enough to work in actuality. There you can use the "tolerant constraint", and if it works within your set tolerance, you are fine.

 

[Thompson]

And I have the solution:

View attachment 25633

*DRUMROLL*

I figured that since this is a rounding issue the solution would lie not in calculating the new distance but rather using variables in calculations to determine the lengths. This cuts out any and all rounding errors.

See that attached package. It uses a global variable file to do the necessary maths. Note the following Variables:
X001 = Brace 1 Length
X002 = Brace 2 Length
X006 = Brace 3 Length
Brace three has, to my understanding, been the troublesome one due to the aforementioned rounding. By using the global variable file and entering the required sizes for X001 and X002 it will calculate the correct distance for X006 without rounding.

View attachment 25635

The attached package is for right angled triangles. Feel free to modify as needed.

Now... bow and kiss the ring...

I'll hang on to my kiss for now, thanks. You have a square root there; of course there's rounding. Also, don't forget; the length of brace 3 has already been "fixed" and its drawing published, as it is used in other structures; so using an equation to change it a little is not really kosher. Besides, that fantasy-concentric mate may also be required where the geometry is not a simple right triangle. I think we're getting into "I see no problem with using tweezers to build a battleship" territory here. The cheat I often use in SW (if all else fails) is to take an invisibly tiny chunk out of the round hole (making it keyhole shaped) and using a "width" mate. The deformation is too small to show up on the drawing, the model works and I get to go home before midnight.

 

[bigseb]

So let me understand this: you guys have a rounding issue, I present a solution and your response that its for right-angled triangles...?

Its the method that is important! You can apply formulae using variables to all your problems and the rounding problem you have is a thing of the past.

 

[Lew_Merrick]

JST -- I will agree that tolerance display (such as expanding or contracting Linear Features based on Tolerance Values) is long overdue in the CAD universe. However, that joins a long list of things that the Powers That Be controlling that universe have gone out of their way to ignore. The real difference is that hand or spreadsheet calculations should easily verify the form and fit resulting from a given tolerance and allowance. It's not all that hard or complex. I learned to make those calculations back in the days of ruling pens and drafting linen.

 

[JST]

The issue here is NOT finding the distance. As far as I can determine, trigonometry still works.

The issue is NOT determining the tolerance, that is already known due to standard hole oversize amount. (remember, this is field assembled steelwork).

The issue is NOT having every constraint "tolerant". The tolerant fit is for certain cases, just like any other constraint. They all have their places.

The issue IS getting Alibre to place the part, CONSTRAIN it, and thus verify the fit.

Another part of the issue IS that the parts WILL NOT BE MADE PRECISELY, they will be made to 1/32" increments, or the like, so 6 decimal places have no meaning. The models will be made to the nearest shop increments, just like the actual parts. (Steelwork is not like machine shop work, it is full of approximations.}

Obviously, if the part constrains, the calculated (etc) distance is correct.

When there is any tiny and insignificant actual difference, then Alibre will NOT allow the constraint. A miss is as good as a mile, the program is howling "IT DOES NOT FIT!". Due to the shop increments, this is not uncommon with diagonals.

You can measure for tolerance, but it STILL does NOT constrain, and still allows the model to fly apart even if it is within tolerance.

What is missing from the toolkit is a constraint into which one can effectively "put the tolerance", and which will allow that constraint to be applied (to keep the model from coming apart}, and at the same time verify the fit is within that tolerance. (if it is not within that entered tolerance range, the constraint will still not work).

 

[Lew_Merrick]

JST -- You need to learn how to use Constraints! The only time I have had probles such as you continuously describe was with the "Design Intent Manager" that was built into ProEngineer;s Wildfire 3 version. I recently designed (and built) a device to hold and play acoustic guitars in various styles for a group intent on upgrading the MIDI standard. It has more than 40 Variables establishing it's correct positioning and adjustment to allow a guitar to be played (mechanically) as a classical guitar,, flamenco guitar, "folk" guitar, "Kansas City Blues" guitar, etc. The Assembly Models of the guitars in question are imported (as STEP files), re-Constrained to meet Alibre requirements, fit into the device, and adjusted according to the Design Variables without a problem whatsoever. There are six major Sub-Assemblies (ignoring the guitar itself) that have to correctly relate to one another based on (A) the editing of Equation Editor Variables and (B) Geometric Features of the guitar model itself. I spent about 3 hours training 2 of the users how to make the "changes" previously described and they have used it (virtually daily) for a year now without an untoward incident!

It's not that hard.