A problem to big to report (?)

[TomD.inPDX]

I have reluctantly employed Creo 3.0 M020 in a production environment.

I now have a significant investment in effort and this project is moving forward this way.

Okay, that's the stage... and I am certain my issues are not only Creo 3.0 related.

As many of you know, I have gotten pretty good at submitting concise support cases...

but this one is befuddling me.

If you regularly create 3D curves using intersect, and regularly use datum references (the Datum Reference feature selecting curve chains).

As you might have guessed, I am in a spider nest of wires. See if any of this sounds familiar:

1. I create the intersect feature of 2 planar sketches. Nothing magic here; often you get a lot of extra intersects that are not continuous but valid.

2. You create a datum curve reference by selecting valid segments of the intersect feature... continuous of course.

3. The direction arrow are all aligned when I exit the reference feature creation.

4. When I try to locate a point along the datum reference, it fails to use the along value.

5. You edit feature the Datum Reference and you find the segment directions in all different direction then form when you left it.

6. Once redirecting all the segments, the point feature can be placed along the entire length (ratio 0-1).

7. You pattern the points; 1st point at ratio 0... and 10 more at 0.1 along the entire reference curve.

8. You then make a datum curve using the points; the 1st one is tangent to an axis, and the last leg is defined straight.

All good, right? Now you expect this to remain stable.

BUT NO!!! Every so often, you will get the 0 end of the Datum Reference to swap. This plays havoc with the tangent vs. straight segments of the datum curve because it too switches ends.

What did make it worse was when I also selected vertices to create the datum curve. These would get all tied up.

So, if you do this on a regular basis... What have you learned? Have you filed support cases?

Did you just give up and just live with it? Or do you just export a successful attempts and lock in?

I've dealt with this for over a week now so I am not just whining... there is a genuine reliability issue here. And not one that only happens every blue moon... it happens at every moon phase known to man.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[dschenken]

Wait for Creo 3 M180. Pretty sure it will be fixed by then.

[James62]

The post pretty much explains it in all of necessary details.

The fastest way to overcome the problem now is to create an independent geometry feature, and collapse all of the point features into it, so the points remain where they are for good.

[TomD.inPDX]

Ha, yes, it explains it but I don't have the time to spend 3 hours on the phone with CS to reproduce it for them. ...and of course, they will condense it to a paragraph like I did... and I will get a reply saying it is not an issue... I have to escalate it... and suddenly the original problem will magically transform into a problem with annotation... which is covered by 9,426 active SPR's.

I need these to remain dynamic.

• X-sketch
• Y-sketch
• intersect
• datum reference (curve)
• point along reference
• pattern points
• datum curve through points (adding unrelated vertices makes it worse).

I should be able to change either sketch or move any of their references.

The sketches are robust enough to maintain the intersect but things fall apart at the datum reference, the point order (ends switch), and the datum curve selection order.

Explain independent geometry feature a little more, please. There are probably good ways to use this for locking thing in place once I get done with all this fuss.

I know I have reproduced the above routine nearly 40 times now. I've gotten pretty good at it

[James62]

I'd think you can create coordinate systems at locations of all points, and then offset points from those, but I'm not sure about that, would need to try.

I know it's pain to redefine an existing datum curve that goes through more than two points.

Well, if you have had Style feature and Flexible Modeling life would be easier.

See the two following threads to figure out how to put together Independent Geom and Collapse Geom features.

Re: How do you untrim in Creo Parametric?

Where is the command of "Collapse Geometry" in Creo 1.0?

Uhh and 40 times? I recommend going back to Creo Parametric 2.0 M140, and just redo all the work there. Much less painfull in the long run.

[TomD.inPDX]

Thanks Jakub. I will definitely have to play with those some more.

I will see about making a video for PTC in the near future for the use-case and submitting the support case.

This, along with sending the reference file, makes support cases a lot easier to manage.

[dschenken]

Did you get a later build yet? How did this come out? Inquiring minds want to know.

Also, what the heck sort of convoluted heap were you trying to build anyway?

[TomD.inPDX]

Even better, this client had convinced me that I needed to move to SolidWorks for follow-on product.

I will fall back to Creo when I need to but in general, everything production must be sustainable in SolidWorks.

I am still holding back on all my other clients on Creo 2.0 and even that is still at M040.

I haven't heard Brian say anything about a version good enough for NASA, so I know the quirks I have now and it is easier to just keep going.

I will try the latest Creo 2 and Creo 3 on the new Lenovo P70.  Haven't done the full swap yet.

The project was fiber management with critical routing and radius control.

I suspect nothing has been done on this issue.  It probably works exactly as expected... flaky on revision

[dschenken]

All I can think of was that the accuracy should be absolute to prevent variations in evaluation that relative accuracy produces. Depending on the algorithm PTC is using the accuracy could affect where it first finds an intersection and therefore what end is the initial end.

I'm guessing by fiber you mean optical fiber/wire/cable sort of routing. I just use sets of datum points; I haven't recently used intersections because they are a pain to manage and they can get tiny fragments. I know I used them for a while, but gave them up.

For example, I did a bunch of fables (faked cables) where they wanted the individual wires depicted. The models used intersections to begin with, but they were not aligned with the terminals in the connectors and were unable to easily depict splices and jumpers (like a loop from pin 1 to pin 2)

Very easy to do with datum points and curve through points. Splines are good for the relaxed sections, but defined radii transitions can be used where that control is desired.

[TomD.inPDX]

It was definitely something that was switching end for end between edits.

I was making fiber optic cable loops going around ~270 degrees with very specific endpoints.

The intersect of the curves created multiple paths but continuous, and therefore I could choose one path for a sweep trajectory.

It is that selection that would reverse, and in some case, switch the selected curves, even when I used the datum reference curve selection.

This is not a normal operation for me, but estimating cable routing is something I do at least once a quarter.

Some techniques are simpler and more straight forward, but this one had a critical requirement, obviously, being large diameter glass fiber bundle.

Obviously I didn't have time to deal with the Support Case although fairly easily repeatable.  I suspect the answer would be exactly what I normally get, "works to specifications".  That doesn't make my work any easier.  I got use to the routing for making changes but the particular challenge took nearly 3 times as long as it should have.  But it got done and it got done correctly.

[psobejko]

Without having your geometry it is hard to experience the problem.  If I try to follow your procedure with some made-up geometry, things seem to work okay here.  One question I have is instead of using a datum reference feature, did you try to use a composite curve as the basis of sweeps, points spacing, etc..

You know what I mean? - using the copy-paste function: select one of the segments, ctrl+C, ctrl+V to start the "copy curve" feature; before you say ok, go to the reference details and add the other segments:

Who knows, maybe that is a more robust method?

[TomD.inPDX]

As a rule, I don't use copy/paste on geometry.  Not reliable enough for my taste.

Intersect a parabola with a cylinder.  Make the parabola tangent with the cylinder.  Intersect.  Now you have multiple solutions.  Select a continuous datum reference set of curves and sweep along it.  Edit the cylinder (with parabola to follow tangent) and watch your datum reference selection swap end-for-end (ties itself in knots).  Fix by re-ordering the references.  Next time you edit, may work, may not.  But when it does, which was often, it took time to re-order the datum curve references.  Please note, the datum curve reference I am talking about is not a datum curve, but the reference selection from existing curves.  And this is fiber-optic, so yes, that should about explain what I was doing in a way that I could change my interface components easily and watch the update in this spider web of fiber optic.  From there I could interrogate the resulting bend radius from the cylinder element.  (~270 degree spiral/tangency control/space-claim/dynamic assembly/etc.)

It is what it is.  And I certainly don't expect PTC to put a bunch of effort in an age-old feature.  When they tinker with things this close to the core, other things break!

If I ever capture the event, I will post it.

[psobejko]

I think I see what you mean; if this is representative of the issue then you're welcome to submit as "evidence" to PTC:

In the example illustrated above, the pink sweep's origin trajectory is the projection of the parabola onto the green cylindrical surface.  As the parabola is moved upwards, sweep geometry "jumps tracks" (A)->(B), or inexplicably disappears altogether (D).

[TomD.inPDX]

Thank you, Paul.

What you show is the very reason I doubt this can be managed.

In my case, the sharp bend in the curve remains tangent.

It is the intent chain that gets messed up.  The datum intent curve is a specific tangent series of the intersect (red) created by the two sketches (green) for the sweep to follow.  Intent curves have a very specific direction and priority.  This is what swaps between edits from time to time.  Below is a very (VERY) simplified version of what I was doing (x TOO MAY TIMES).