An illustration of the resolution problem behind asking for "approximate" alignments.

[admin] on page 2 a diagnosis, explanation, and alternate modeling approach is explained. This behavior is expected.

The attached frame has a diagonal that measures the same as the diagonal dimension it is to align with.

It will not align. I know why it will not, I set it up that way on purpose as an example.

There is a difference in the actual measurement between the diagonal bar and the diagonal of the frame. But as far as you can tell by using the tools available, there is no difference. The difference is a couple of decimal places over past what is displayed.

Now, all of us here know perfectly well that if the parts were machined exactly as they are represented here, the assembly would go together, and no QC department this side of the NIST would discover an error.

And there is no reason to worry about "all the rest of the assembly being 'off' on account of this error", the error is unmeasurable by any commercial QC department.

So, it seems pretty silly for Alibre to refuse to align these parts. Yet it does, and there is nothing to be done but to "cheat" the alignment (or use Limits).

It seems eminently practical to allow a settable number of decimal places inaccuracy or error band to be allowed in an alignment if desired.

The way I see it working is that the alignment would attempt to put it in exactly, and would do that if possible. The difference is that if that is not possible, but the error between the exact and the possible positions is within the error band, then the alignment would proceed without error.

We could argue about whether the position of the resulting alignment should be considered as its true position, or as the position of the fixed axis (etc) to which it was being constrained. I see decent arguments for both, and I suppose it would be best to do whatever is the easiest to do, since we have already decided that the error is insignificant by allowing the error band to begin with.

This idea differs from the limits option, because limits is dynamic, and there is even a warning about using it this way, because of the resources it uses. Limits does work here, of course. If you set the limits parameters to 0.000001", the parts will align. But you do use unnecessary resources.

I see this as static, there is no good reason why it should be dynamic, it can be aligned and fixed there without any capability of movement beyond what is allowed for any other use of the same constraint.

The only case for re-evaluation of the constraint would be if another constraint was added that might shift the position of the diagonal bar in this example. If that shift were still within the allowed error, then no error should be thrown.

Alternately, the added constraint might have to be made with the use of the error band on it's alignment, which would not require any re-evaluation. That is probably the simpler and more reasonable approach, as it removes the apparent need for Alibre to "read minds and decide what you really want".

I see this mainly in the coaxial alignment case, but there is no reason that it should not apply to others. And I see no reason why a small error of angle between the axes of the two holes (or two planes, lines, etc) should not be included as a settable error band in the alignment. There may be errors of distance, or of angle.

I would not hold out for that angle error if it meant the difference between getting the option or not getting it. However, it seems entirely in-keeping with the idea, and desirable if possible to do.

 

Yeah something odd there. You've brought this up before but this is the first time I see it myself. If it is down to rounding at a miniscule level then it makes me wonder how many other ops could fail because of this. For example, I sometimes have boolean ops fail on scaled parts. Perhaps for the same reason?

 

I looked into it more and found Solidworks only just added such a feature in the 2018 version and it has the option for users to enable/disable that ability entirely system wide. It gives the user per case options something like "keep prior aligned", "align to this one", or "spit the difference". So it's not impossible. However every example they showed was between holes in only two parts - I think any more than that and it still would require dynamic movement calculations.

 

Bigseb: I would suspect it is very likely to be involved in odd failures of operations. Scaling would be something that might result in rounding errors or other causes of differences between numbers which should nominally agree, but which were calculated different ways. I expect that Max and company are well aware of what goes on "under the cover", and might be able to clue us in (depending on any NDA situations).

NateliqGrav: The solidworks system you describe I was unaware of, as I have not used that new a version. But it sounds very much like what I envision as the way to do it.

I am not too clear on what the reasons for it to have to be dynamic might be, or what is meant by "more than" only holes in two parts. Two holes aligned is sufficient to define position in a plane, and any related coincident constraints (probably mates or offset mates) would take care of the remaining axis.

Would it be what you are talking about if a second diagonal bar were to come from one of the remaining corners and go to a hole in the middle of the first diagonal bar? I may be missing something, but I am not clear how that would require it to be dynamic.

I suspect that one end of that second bar would likely have to be done via the error band alignment as well. But once done, it seems that it would be OK to let it be fixed rather than dynamic.

Setting up this case:

What I did was to deliberately make the dimension between holes on the square frame a dimension with several decimal places. And, since the diagonal of a square is the square root of two x the side, which has as many decimal places as you care to use, I could be assured that the dimension would go well beyond 6 places. So I entered the number in decimal, and put it in to 8 places, not knowing if the program would simply truncate it or use those extra 2 places.

The result was that the diagonal, which lacks the full (19 or so?) decimal places that are used internally, would look like it equaled the actual diagonal, but would not actually match beyond 6 places (or 8 if not truncated on entry).

 

Rounding and many other issues regarding precision, especially equality comparisons between what 'should' be identical values, are old and well known programming issues with floating point numbers. There have been many whitepapers on the subject and some simple explanations ...

https://possiblywrong.wordpress.com/2013/11/15/floating-point-equality-its-worse-than-you-think/

https://floating-point-gui.de/errors/comparison/

... the trouble is, that in an application like Alibre that relies on precise numerical data (to small decimal precision) to do simple operations like constraints or even scale, things fall apart very quickly unless you accept that values comparison needs a tolerance and the program explicitly overrides the 'default' method of doing it.

Saying that, most programs don't need precision, so the default mechanism is good enough, but some need to work at it and most avoid using the equals comparison on floats/doubles. The one main reason why automotive and aerospace electronic control units (ECU's) use integer based maths, and not floating point!

 

no comment...

 

I just remember how Creo let you set a model tolerance. Set the tolerance to fine for imported parts and subsequent operations would fail.

 

No idea what you posted, as you use V22 and I.................... do not.

But if it was a way to make them align, I know how to do that. That is, to "look like" they are aligned. The issue is just that... they "look like" they are aligned, but the part is actually held by some other means in the "approximate correct position", OR is aligned by the method of using the limits option.

The other method is to relax the perpendicular requirement on the sides, so that the frame can distort to fit the diagonal. That is a "situation specific" solution, not a general one, and actually propagates the (admittedly very tiny) error throughout the structure (that was complained about earlier by another poster). Furthermore, it does not work at all if the frame is a solid structure, and not assembled from bars.

Aside from that, the frame dimensions can be individually modified in length to make it fit, assuming the tolerances are such that the precision of size can be relaxed. That works for "made" dimensions (individual parts, or simple assemblies), but not well for "derived" ones (dimensions from point to point between widely separated parts in a more complex assembly). And, it is again situational; there are cases where it is fine, and others where it is either difficult, or involves modifying parts away from their specifications.

Attempts to evade the need for this are probably futile, since several other packages already have the capability (a fact I was not aware of until now). One assumes they found the need to have it was valid enough to actually program that as a feature.

 

I submitted a "new feature" ticket on this.

Thanks to Bigseb for mentioning that other software such as Solidworks has added this. That provided solid "outside validation" for the idea, which was helpful because when I mentioned it here in the past, I was nearly lynched for suggesting it.

Obviously, although I was unaware that any other packages had it, enough need exists for them to have added it. Probably at least some of it comes from the "structural and construction world", where an error of 1/32 inch is regarded as "precision", but the utility is not limited to those areas.

 

I never mentioned Solidworks...

 

Correct.... it was NateLiqGrav. you mentioned Creo. Sorry..... (what, you did not want credit for a good comment?)

 

I reviewed the Solidworks help and it only allows misalignment for between 2 parts (each with 2 holes).

So it still wouldn't help you for any diagonal brace involving 3 or more parts.

https://help.solidworks.com/2019/En...ks/t_allowing_misaligned_concentric_mates.htm

 

Not if it wasn't mine.

 

How do you come to that conclusion? I think you are misinterpreting the statement. It says "If you have components with two holes, ..." not "two components". They are only using two parts for the illustration. I think that the constraint would allow you to apply the constraint between as many parts with two holes as you need to.

 

I would normally agree, not sure what limtations there might be to this though (thinking in terms of model stability).

 

I have access to Solidworks 2018 and tried it and it only gave me the option when it was two sets of holes involving only two plates.

 

I stand corrected, I guess there's no proof like testing the real thing.

 

How many holes do you want to align? You normally only align one hole or surface etc to one other feature at a time. We do not have "multiple simultaneous align" (yet).

Are you saying instead that you can do it only once in an assembly, and that is the only time you can use it for that entire assembly?

Or, is it that if the parts have more than two holes, even if you are only aligning two of them, that it fails?

 

The number of extra holes per part doesn't matter.
The number of parts in the assembly doesn't matter.
You can have more than one misalignment constraint.

Here's how it works in Solidworks: A misalignment constraint is a special constraint that combines two "concentric" mates with a tolerance that is applied to either the first concentric, the second concentric, or spilt evenly between them.
Both concentric mates must be applied to the same two parts.

You apply the first concentric mate like normal Part A to Part B. When you try to apply the second concentric mate Part A to Part B it sees the misalignment and offers the option of creating the misalignment constraint.
You can then create a misalignment constraint and the first and second concentric mates get absorbed into the misalignment constraint.

 

Ah, that is rather limiting. Probably "useful sometimes", but not in many typical cases.

If I understand you correctly, the example I presented could NOT be done with Solidworks, for example, because the diagonal involves 2 different parts plus the diagonal itself.. Each end of the diagonal is on a different part.