Sweep again - how to explain this?

[BHOoi]

I guess i am having bad day today . While working on the sweep problem posted earlier, I found another strange thing in sweep. The sweep feature (along half the circle this time) failed, but this is resolved by temporarily alter its relation, preview and then restore to its original equation and the problem gone !!

Anyone can help to explain this ? You can try it on the attached Creo file.

[psobejko]

Makes PTC sense to me

Probably changing the sketch-relation in the original feature to something like sd19 = 1+trajpar*360*3 would also solve the issue, which is that you can't specify an angle of 0 to angular dimensions in sketch...  I don't know why that limitation is there, but I think it exists in implementation, and not in the basic math.  In fact, Creo just doesn't do a graceful job of handling the change of direction "sense" of a dimension - have you noticed you often can't drag a dimension past the 0 degree mark to the "other side"?

[lsrutkowski]

It actually makes a lot more sense when you think of the problem in terms of programming: you can add, subtract, and multiply with an object of 0 length, but you cannot find the discrete start and end, nor the midpoint, of a 0 length object (it is that pesky dividing by zero thing that gets in the way ).

edit: typing way too fast, had to correct a typo.

[psobejko]

Let's take a look at another CAD package; what can "On-Shape" do in its sketcher?

Consider 35 degree angular dimension.  You double click on it, and you can type in any number - and the result just makes sense.

In Creo sketcher, only non-zero positive values are allowed???  This does not make any sense mathematically...  Wait, I have an idea; what if, way back in early days of Pro/Engineer 1.0, in some calculation, they started to divide by this angle to determine the placement of sketcher dimensions.  Yes, yes, that could explain why they just seem to fly off to infinity once in a while.  And of course, division by zero isn't mathematically allowed, so user was stopped from making the system crash.  And it has worked to specification ever since, so there is no need to fix it; I think I just cracked it!

But there's more!  look above and see the "0" dimension?  You specify this to be 0, you get the shown triangle; if you type in a positive number, you get a parallelogram like thing; you type in a negative number, you get a bow-tie looking thing.  I don't show it, but you can actually draw another line from origin to the midpoint of this line (after making in non-zero in length) and turn it back to 0 length and things just work and make sense.

In Creo, the "0" case is not allowed; ah, at least that makes some mathematical sense - there is a singularity there.  But it isn't and should not be a show-stopper.

So don't make excuses for PTC as though there is a fundamental reason the software is so clunky; it's not the math, it's that PTC doesn't invest all that much on improving the user experience (and why should they? people would stop paying them for training!).

[dschenken]

The original Pro/Engineer sketcher inferred constraints from the geometry. The lead to cases where zoom state affected the how Sketcher applied the inferred constraints. Trying to create an 89.9 degree angle was frustrating.

With a zero angle it can't determine the sense of the angle, which could be positive CW or positive CCW. Sketcher Manager makes its assumptions more visible but, for every change, seems to re-evaluate from scratch to determine any constraints that aren't strong, so when the number is '0' it can't determine which direction is positive and which is negative.

It could be better, but changing the angle basis from a nominal '0' to a perpendicular that is nominally '90' works OK.

It looks like On-Shape deals with the problem the way a mechanism solver does. Typically different answers to similar UI problems generate different badly behaved cases. It's what I call a plateau, where the many answers are no higher up, just in different locations.

[psobejko]

Hmm, can this be managed by simply having the rule "in ambiguous cases, assume positive = CCW"?

Onshape allows you to enter +225 or -135 and it leads to the same geometry.  So the sign seems to keep track of the "sense".  I'm curious if you have insight as to what "trick" or "assumptions" are they keeping hidden from the user and in what situations does their solution behave badly?

[dschenken]

Create an Idea and vote for it.

[Kevin]

‌I also wonder if there are issues from one date code to another. For me, when I edit this and the other examples you posted, the angle isn't the problem the section width and height dimensions are. I can set the angle relation to trajpar*360*3 and the section will regen just fine as long as the section width and height are appropriate. i also had some success by changing the accuracy type or value or both. This example also seems to want dimensions that are defined differently than the other examples you posted.

[psobejko]

I wonder if you can do this test.  At least in Creo 3.0, M120, this is what happens to me:

Take the "working" variable section sweep shown in the op (1/2 circle) and change it to non variable type.

Edit its sketch and remove the sketch relation sd19=trajpar*360*3.

Notice the 0 dimension stays in the sketcher -> no problem?

Well, change the 0 degrees to 5 degrees; the rectangle tilts.

Now try to change it to 0 -> the system won't let you comes back with a message "Range is 1e.0e-5 - 1.0e+06".

Ok, so keep the 5 degrees.

Accept the tilted sketch.

Preview shows up.

Now you can change the 5 degrees back to 0 degrees and it all works well ???

If it's the same with you then I say all just sketcher bugs and hence the need of the arcane knowledge on how to sneak up on these "singularities".

(still baffles me what problem an angular dimension equal to 0 degrees presents...)

[Kevin]

‌The trick is to change the value for the angle outside of sketcher. If I select the sweep feature and select edit which shows the sketch section values I can change the value for the angle and the system accepts it. When I add the relation I don't need to add an additional constant for an angle offset but section width and height values seem to have a range that works for the geometry. I have some other thoughts I just haven't tried them to see what I get yet.

The other thing that happens for me creating the model myself, which I also posted in the poster's other post on this, is the dimensions need to be created as a certain type in order for the geometry to generate successfully. I found that creating the dimensions as radial or diameter dimensions worked consistently, creating linear dimensions from the centerlines also worked consistently, creating one of the dimensions as linear and the other as radial or a diameter dimension worked occasionally, and two linear dimensions measuring the full width and height didn't work. If I edit the posted model it seems to want two linear dimensions which is the opposite of what I get and is also the opposite of what I get when I try to edit the poster's other models that are similar.

Makes me wonder if the model was created in an earlier release or could there be changes from one date code to another.

[BHOoi]

I logged this issue with PTC and as expected I did not get any constructive reply from them:

https://support.ptc.com/apps/case_logger_viewer/auth/ssl/case=13584143

[BHOoi]

I am still on Creo 2.0 M130. I hope you are using newer version so that I can assumed PTC has somehow made some improvement.