We’ve had an issue since back in the V6 days where text created by the TextObject command sometimes produces invalid curves. Running the What command produces this note:
Geometry:
Invalid curve.
Collapsed polyline with 3 points.
(-42.100,-73.243,24.900), (-42.100,-77.538,24.900), (-42.100,-73.243,24.900)
domain = -8.591 to 0.000
It’s not an issue that I can repeat on demand, but it does come up at least once a month. We notice it because it causes our toolpaths to peck at the curve like a jack hammer.
Hi Dan - I see - these are closed polylines with duplicate segments - are you saying this only happens sometimes, with the same font?
Explode > deselect> SelDup > Delete will clean up.
Yes, the TextObject command usually produces curves that work well with our CAM software. This issue only comes up maybe 1 out of every 100 times. I’ve tried exploding, ungrouping etc. but once this happens I can never get the text curves to behave correctly in our CAM software. We always end up with the excessive retracts. The only solution is to remake the text. We always use the same font so I don’t know if this would happen with other fonts.
The green text in the file I posted will engrave efficiently as it is. However, like I mentioned, occasionally the TextObject command produces the red text. I’ve never tried to convert the segments to arcs, but I’ll try that on the red text in the morning.
I guess my real question in all of this is why does the TextObject command occasionally make invalid curves?
No, I’ve tried that. I always end up with the same results in CAM. The only solution we’ve found is to remake the text. It’s an easy fix, but like I mentioned to John, I’m wondering why we sometimes get bad results with the same command that usually gives us good results.
Hi Dan - ok… I am doubly curious - why it happens, and why the proposed fix fails - possibly due to random curve directions, would that do it? If so, Join then Explode after the deletion of the dups may get the segments all going the same way.
I’m going to dedicate some time to this in the morning. Maybe I can determine what triggers the TextObject command to create invalid curves occasionally. I think I’ll also see if I can script a check so if this happens the user will be warned that the curves are invalid before it gets to the CAM programmer.
Did you notice that the invalid text is slightly longer than the valid text, but they are the same height? Can you think of anything in the generation process, or subsequent usage, that might result in a slight stretch?
Good catch. I hadn’t noticed that. I wonder if the users are manipulating the curves with the gumball and that results in the invalid curves? That would make more sense than any inconsistency from the TextObject command.
I think I’ve figured out what’s going on here. The good news is that it doesn’t look like there is either inconsistent results from TextObject, or that the Gumball is causing issues. I believe the users may be neglecting to check the Engraving Font checkbox. I can replicate the red text in my file by unchecking that box. When that’s the case, exploding, deleting the duplicates, and re-joining does fix it.
Now the question is why this fix hasn’t worked for us before. I know we’ve tried this in the past and this didn’t solve it for us. I’ll keep investigating on my end. Maybe I will be able to determine that this issue is being caused by a single user, and I can examine their process to see why they end up with unfixable text curves.
Hi @DanBayn
I run into this with my cutter. If I have two dup curves nothing gets done that line is skipped. So I made a study of this and found indeed seldup works most of the time except where I might have altered something and the curve is not really a duplicate but could look and be cut exactly like another curve. Mostly stuff that has been split and is rejoined or stuff that has a control point added. Then it’s really troublesome you have to go in and select by hand. That’s why a number of years back I got a script called selsimilar from @Helvetosaur.
I attached a file of what might occur for seldup to fail well not really its fault.
