Simple geometry won't offset

Rhino
1

I’ve come across something I don’t understand. I have some very simple shapes, just triangles with filleted corners. Most of the time they are fine, but sometimes I can’t offset them. I can force an offset to happen, but that’s not why I’m trying to figure this out… when the triangles won’t offset, I also get a glitch in my CAM program where there appears to be a microscopic break somewhere, and it’s very difficult to find and even more difficult to fix. I have tried all kinds of things to clean up the geometry like project to Cplane to make sure it’s flat, and re-drawing the fillets and making sure they are trimmed to the lines… I always make sure when I join them I end up with a closed curve, yet I end up with some like the one in the sample drawing attached that I can’t offset… when I start the offset command, it shows the offset in the preview:

Screenshot 2023-06-20 051205
Screenshot 2023-06-20 0512051655×867 15.8 KB

.

but when I click on the side I want to offset to, it just disappears and it says

Curve offset into one open curve.

I don’t understand this at all, when I joined everything it says it created a closed curve, and I should be able to offset any closed curve to another closed curve, why is this one resulting in an open curve? I can see the tiny segment it makes:
Screenshot 2023-06-20 052419
but I can’t figure out how to fix it… I’ve deleted the fillet and re-drew it… I’ve deleted the line and drew a new line tangent to the two curves. I’m baffled by this. Can anyone figure out what is wrong with my geometry and tell me how I can detect the problem and fix it? I have verified that I have G1 Continuity with two methods, if I explode it, and try to select it with SelChain and set ChainContinuity=Tangency then no matter where I start the selection, the entire filleted triangle is selected. or if I analyze each pair of entities with _Gcon it reports each pair are all G1… soooo??? I just can’t understand what’s happening here. If I have a closed curve with G1 Continuity, then why can’t I offset it to the outside and get another closed curve with G1 Continuity?

The parameters I am using are:

Side to offset ( Distance=1 Loose=No Corner=None ThroughPoint Trim=Yes Tolerance=0.001 BothSides InCPlane=Yes Cap=None OutputLayer=Current )

I can turn on Loose=Yes and then I get the offset, but that is not resolving my problem. The offset I just use for positioning these, it’s temporary, but I have noticed when I have this offset problem, I also have problems in my CAM program… so I am trying to figure out what is going on and how to clean this up so when I get to the CAM program I don’t have to figure anything out, I can just get it done.

The Offset is only an indicator that there is something wrong and I notice the same thing wrong when my CAM programs goes to offset for the toolpath. I can fix it in my CAM program by re-filleting them, but why can’t I fix them in Rhino?

The problem is, I don’t know they are a problem until I get out on my machine and get an error… then I have to go back to my office and figure it out, fix it, re-generate everything, etc… it’s a major slowdown in my workflow, it would be much better if I could fix this in Rhino when I try to do the offset and see it gets offset into a microscopic open curve. So I have a quick way to verify things in Rhino, just try to offset to the outside… but I have no idea how I can fix it.

When I can offset to the outside and get a closed curve with Loose=No then everything is fine from then on. If I get an open curve, then it’s messed up all the way through and I have to keep battling with it.

sample.3dm (50.9 KB)

Any help is greatly appreciated!

2

Hmm, I can offset all three green triangles in your file 1 inch both inside and outside, no problem…?

1 Like
3

That’s odd… why can’t I offset just that one? Do you have Loose=No ? I can get the offset on that one with Loose=Yes. The drawing should be in inches and I was trying to do a 1 inch offset.

1 Like
4

Yes, didn’t notice the drawing was in inches - the offset is 1 inch. Yes, it’s Loose=No, I used the same (basically default) settings as you.

1 Like
5

Thanks for trying it. I don’t know what could be wrong. I closed it and re-opened it; I still can’t offset just that one. I’ll try on another computer. Could there be some Rhino setting wrong somewhere? I just made a drawing using Small Objects - Inches and I thought all the tolerance settings were defined in that template.

1 Like
6

Ah, wait, I found it. You have Corner=None. Use Corner=Sharp.

This is interesting and looks sorta buggy. It depends on where the curve seam is. With History recording on, I first ran Offset with Corner=None. The result failed - actually it makes one microscopic curve segment. I showed the curve seam. I then ran CrvSeam multiple times and changed the location of the seam. At some spots, the history-enabled offset appears. At others, it doesn’t.

In any case I would always use Corner=Sharp unless there is a reason not to. If you have G1 or better closed curves, you won’t notice anything and looks to be more reliable. If you have kinks in the curve, Corner=None will not connect the offset segments together at the kinks (try it on a rectangle to see).

Additional edit:
If I set Trim=No the offset also succeeds. So something may be going wrong trying to ‘trim’ the offset segments to each other. Don’t know why. However, looks like all this may be moot, the offset appears to work even with Corner=None in the current V8 WIP. So the bug may already be fixed, but will not be back-ported to V7.

2 Likes
7

That explains a way to make the offset work… but the question remains, why can I offset the other 2 triangles with Corner=None but not this one? I have to check this on my CAM system and see if it has the glitch

1 Like
8

That’s very interesting… maybe if I just move the seam until I see the offset work like in your video I won’t get the glitch. This may be a solution. I would much rather move the seam around in Rhino until I see the offset works. I didn’t know the curve seam could be moved. As I mentioned, I’m not trying to get the offset done, I’m trying to figure out what causes the glitch in my CAM program. I think that when the seam is in the wrong position, I get the glitch and when it’s not I don’t get it.

Interesting that V8 WIP doesn’t behave like this, maybe whatever the issue with the seam is has been fixed. Maybe all I need to do is open my drawing in V8 WIP and use that.

Thanks for the help!! now with CrvSeam I at least have another way to try different things to see if I can eliminate the glitch. Just knowing that it is related to the position of the seam is a big help.

1 Like
9

When I try to duplicate what you are doing in your video, it doesn’t update automatically based on history. How do you turn on the history update feature?

10

Before you run Offset, left click in the history panel in the status bar once to activate history recording as a one-shot for the next command. If you want history recording on permanently, right click in the same panel and check “Always record history”.

I am curious, what exactly is the “glitch” when it happens?

1 Like
11

I am cutting TPO with a tangential wheel cutter.
C is the rotary axis that keeps the wheel tangent to the cut.
I get an extra G0 move when it crosses the curve seam:

G0 X25.0919 Y37.2918
G0 X25.0919 Y37.2918 C143.67
G1 Z0.03
G1 Y37.297
G3 X25.0798 Y37.3007 I25.0851 J37.2968
G3 X24.9406 Y37.0931 I27.3959 J35.5975 C148.652
G3 X24.7867 Y36.8048 I27.3959 J35.5975 C155.1687
G1 X24.5911 Y36.3819
G3 X24.5902 Y33.969 I27.2003 J35.1746 C204.7929
G1 X39.5677 Y1.5444
G3 X42.1777 Y-0.125 I42.1777 J2.75 C270.0001
G0 X42.1777 Y-0.125 C270
G1 X42.5685
G3 X45.1785 Y1.5444 I42.5685 J2.75 C335.2071
G1 X60.1565 Y33.9701
G3 X60.1557 Y36.3831 I57.5465 J35.1757 C384.8313
G1 X59.96 Y36.806
G3 X57.3507 Y38.4736 I57.3508 J35.5986 C450.0022
G1 X27.3958 Y38.4725
G3 X24.9406 Y37.0931 I27.3959 J35.5975 C508.652
G0 Z2

This triggers an error in the controller because it is a rapid move that is below the clearance plane, and all rapid moves should be above the clearance plane or you risk hitting mechanical clamps.

Also the C270.0001 is strange, it should be C270 exactly… and after I fix it, it is C270 I even turned on more decimal points to see it really is C270.000000 now

G1 X39.567662 Y1.544397
G3 X42.177671 Y-0.125 I42.177671 J2.75 C270
G1 X42.56853
G3 X45.17854 Y1.544398 I42.56853 J2.75 C335.207087

Sometimes I get a whole bunch of errors and they are difficult to track down because I have a lot of triangles all rotated and nested on sheets. I discovered that it’s always the triangles that give me a hard time when I do the offset that end up with this glitch… So I’m trying to solve the problem before I even export from Rhino because it’s way easier to verify the geometry than it is to find where the problem is later.

1 Like
12

Hmm, odd - is the ...G0 CNNN move a normal thing when a G0 kink (sharp angle) is encountered? Like if you were to cut around a rectangle? (I would think it would lift first, turn and then redescend). Because maybe the program is detecting a non-tangency that is way smaller than the Rhino tolerance.

I’m simply wondering because maybe V8 has solved the offset problem internally, but the issue with the original curve is still there to be detected by your CAM program…

I’m also surprised that is is detecting/resolving 0.0001° - that’s sooooo tiny.

1 Like
13

If I cut a rectangle, it will lift and reposition the C and put it back down… It can’t turn the wheel while it’s engaged in the material. I think there is some tolerance for this so you could maybe cut a file that had interpolated line segments as long as the angle between each segment wasn’t too great it would probably work, but I haven’t ever tried doing that. This whole cutting with a wheel thing is a new process for me,
I know things need to be tangent and it works best if I have true arcs (not NURBS). Rhino is exporting the arcs correctly, so I don’t have the re-draw them.

The only G0 moves that should happen below the clearance plane are Z only moves that get the head up above the clearance plane. This is the first time I’ve seen this kind of thing… but It’s happening on like 50% of my parts, so I’m trying to get to the bottom of it.

I will have to try V8 and see what happens. The thing that is really strange is that even if I turn on 12 decimal places, I see NO difference between the X and Y values… it’s only the C that is off… even though the end point is exactly correct. After I fix it, I can’t see any difference whatsoever, other than now it works… but analyzing the entities involved show no difference at all.

14

In the file you posted, at the point where the offset is failing there is a microscopic line. You can’t see it but if you Window select it will report “1 open curve added to selection”. You can then turn on control points and see them.

That tiny line is right at the point of the offset of the seam and it is the resultt you get when the offset fails.

Anyway if you are exporting that line along with the curves you want to cut then that may be what is causing the problem CAM output.

Also, if you explode the green curve then join it back again the offset seems to work even with the none option for corners. That implies there is something wrong with the green curve that gets fixed by exploding and joining. If I were you I would continue to use the none option as it should work if there are no errors in the curve being offset and when it doesn’t work you know you have a bad curve.

2 Likes
15

Thanks for the suggestion. I’ve tried exploding it and joining it again, and indeed that does sometimes fix it, but not always. I guess it depends on where the seam ends up.

Using the none option with the offset to detect the issue seems to be working well… if I get the offset with that, then everything after that is fine. Also just moving the seam around until the offset works appears to be working as well.

16

If you move the first triangle, which does offset, to the same position as the third, which doesn’t, then it continues to offset. The triangles are ostensibly the same so you’d expect them both to offset or neither.

Using _List to obtain segment and CP positions to 13 decimal places it seems that the two sets are identical to 10 decimal places. This would seem to imply that differences smaller than this are still enough to give differing offset outcomes. This in the context of tolerance being set to just 3 decimal places. Why differences this much smaller than tolerance can make or break offset is the question.

Regards
Jeremy

17

No that is not at all the question.
Tolerance do not and should not play any role in offsetting planar tangent lines and arcs. You should get a result that is as precise as a computer can manage no matter how tight or loose the tolerance is set to.

What are you expecting the tolerance setting to do to the operation of offsetting a line or an arc? Do you expect it to add in some random inaccuracy if the user has asked for a tolerance much lower than the result is? Tolerance is only for operations that can’t be precisely calculated.

The fillet command is supposed to produce lines and arcs that are precisely defined so that they should offset as exactly as the floating point math allows (and that is millions of times more accurate then the user tolerance)

18

Hi Jim,

I’m afraid I must have expressed myself clumsily: I only intended to employ tolerance as an aid to comprehending just how small these differences are. Please take that out of consideration.

Here we have the same triangle, drawn originally in two places (and quite possibly in different ordering of segment construction) resulting in differences of less than 0.00000000001" in the placement of segment ends and control points. One set offsets correctly, the other doesn’t. My question remains: why?

(And as I can’t resist comparisons, for an alternative size indicator, this is way smaller than a hydrogen atom, with a diameter of approx 0.000000004"! But please ignore that too!)

Regards
Jeremy

[Edit: this argument presupposes that the _List command is reporting the positions correctly.]

19

The important thing is to figure out why this offsets incorrectly as the offset isn’t the end goal, his getting valid CNC code is. Something in there is causing the incorrect offset and seems like it is also causing the code problem. I’m wondering if it it isn’t a ultra-microscopic non-tangency at the seam, as his CNC code generator seems to be picking up an angle of 0.001°. That’s soo tiny.

1 Like
20

At a distance of 34 inches, a 0.001° agle would cause a 0.00059" deviation at the far end of the straight line. If you extend the arc with a straight line the new line is coincident with the old one to within 0.00000000001"