Parallel Cylinders for Secondary & Tertiary Datums

[[Ri...]]

Has anyone ever been given a response as to why you cannot use a Cylinder as your Tertiary Datum if it is Parallel to the axis of the Secondary Datum?

What is everyone's workaround for this?

Thoughts?

[[Me...]]

Are you referring to the use within a base / secondary alignment?

[[Ri...]]

Yes, and it will not work if tried inside of a Position/Profile.

[[Me...]]

The release notes mentioned that "Parallel Cylinder" could only be used as a primary or secondary datum reference.
While I've not heard anything official, I would assume that it has something to do with both direction vectors pointing in the same direction.

[[Th...]]

I think the simplest workaround would be to recall into a point-reducible feature like a circle.

[[Er...]]

It seems to me that functionally your tertiary datum would only be located where the most outer tangential surface along the parallel axis is found because you would already be locked down to the secondary datum. You would probably have to use a surface profile to the primary and secondary, finding the most outer tangential surface on each side of the cylinder and somehow finding the midpoint to represent where your zero would be. Why this couldn't be computed within Calypso? I could not say.

[[Ri...]]

Please sign in to view this quote.

The Parallel Cylinder is a different type of feature (like the Step Cylinder, and what not). I'm referring to using two Cylinders that are Parallel as the Secondary, and Tertiary Datums. See the attached gif.

You can also see that it clearly doesn't work inside of Position Characteristics as well.

[[Th...]]

Pre-emptive warning that I'm attempting to explain a concept in my head using words that I'm not sure really make sense, so I apologize if this ended up being word salad.

Calypso's trying to determine rotation in the YZ space. Since the tertiary datum feature is a line (center axis) perpendicular to YZ, there's not a single valid point for the alignment to rotate to. You've theoretically got a single Y/Z location, but X has infinitely many possible values, so rotation has to be determined with normal vectors. That means the tertiary feature needs to have some definable orientation in that space, but lines don't have direction in that, uh, direction, so Calypso just throws up its hands and says no.

I believe this should be the same thing that Phillip mentioned earlier about parallel vectors.
Feel free to slap me down for anything I've just said that's obviously blatantly incorrect, as I'm in one of those 'imposter syndrome' moods today.

[[Me...]]

The position characteristic is creating the alignment correctly; you just have to manually orient the DFR to the desired angle. If you would rather have the DRF initially align to the references automatically, then as Thomas suggested above, use circles. You can either create a circle that uses the same measuring strategy as you would for a cylinder, or recall points from the cylinder into a circle. Either option will satisfy the orientation constrained fit (ISO 5459) if setup properly.

The secondary / base alignment is different story. The planar feature is trying to use the direction vector of the feature. In this case, with the planar feature being nominally parallel to the secondary reference, the software does not know what to do with it. Use circles to fix this as well.

[[Ri...]]

Please sign in to view this quote.

I've heard this argument, and it makes sense to me, but the argument becomes somewhat void when other software (even the GOM software) allows you to build DRFs correctly with no issues.

[[Ri...]]

Please sign in to view this quote.

I don't think you watched it. It won't allow you to select a Cylinder as the Tertiary if it is Parallel to the Secondary. I showed that if you select a circle it will correctly apply it.

The point of me showing what I showed is because if you manually fill out the DRF or the Alignment by selecting the features from the features list it will allow you to apply them, but they clearly aren't working (it is in-fact nulling them and defaulting to the Base Alignment).

I don't mind using a circle if the hole is short, but I'm somewhat conflicted when it should clearly be a Cylinder.

[[Me...]]

Please sign in to view this quote.

Let’s break down each example you provided starting with the first….

Base / Secondary Alignment Menu:
The software is not populating the planar feature as a cylinder when you click it because the alignment function wants to use the direction of the associated features axis. Since the axis of the feature that you’re wanting to use as the planar feature is parallel to the axis of the secondary reference, the software is just going to ignore it. You have to reduce it to a “point” type element. To the best of my recollection, it’s been this way since Calypso was released.

Position Characteristic:
I will assume that all you were trying to illustrate was that the trihedron did not rotate when you used a cylinders as both the primary & secondary reference. As I stated earlier, if you want to see it rotate then you will need to a circle as the secondary reference or in the case of a position characteristic, manually enter the value.

Please sign in to view this quote.

Pro Tip:
If you’re using the ISO 5459 settings as recommended, then a circle with multiple paths at different levels is no different than using cylinder….. Regardless of how long the feature is.

[[Ri...]]

I'm not disagreeing with what you are saying. I'm just confused as to why Calypso can't handle something that virtually every other major software can easily handle - like I mentioned even the GOM software can easily handle this.

I've used workarounds for years, but like I said I'm just not a fan of that.

[[An...]]

_

[[Ri...]]

Please sign in to view this quote.

Makes sense, but I still don't understand why you have to do this. If it is creating the circle for you when selecting the cylinder for the secondary, why wouldn't it do that if you selected a cylinder for the tertiary?

[[Th...]]

Please sign in to view this quote.

Sure, I agree with that. There's not a fundamental limitation here. It could be that programming decisions made years ago by Zeiss's software devs have put them in a spot where changing this would take more developer resources than they're willing to allocate, or the decision makers just don't see this as an important enough improvement to bother with.

[[Me...]]

Please sign in to view this quote.

I get the frustration... Anymore I’ve learned to expect having to do things the long way.