[BUG] join_prism interaction with subdivide_path() is behaving strangely

[dan-p3rry]

Describe the bug
join_prism is behaving strangely, works for some values of plate size and subdivide_path(), but not others. In code below, join_prism() works when y value of poly1 is 10 or 50. It doesn't work for 20, 30, 40. join_prism() also breaks if I change the value in subdivide_path() to 40 or 60.

Code To Reproduce Bug This code works. It breaks if you change y value of poly1 or subdivide_path divisor.

`
include <BOSL2/std.scad>
include <BOSL2/rounding.scad>

$fs = 0.2;
$fa = 3;

yrot_ring_gear_radius = 39.25;

poly1 = square([6, 50], center=true);
plate = subdivide_path(poly1, 50);

difference() {
    join_prism(plate, base="cylinder",
            base_r=yrot_ring_gear_radius - 0.01,
            length=45.0 - yrot_ring_gear_radius,
            fillet=0.01, n=99);
    xcyl(r=yrot_ring_gear_radius, h=8);
}
`

Expected behavior
I expect to be able to use any reasonable value of poly1 y dimension and path subdivision and get a fillet.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

• OpenSCAD Version: Sept 16 download
• Other libraries used:

[adrianVmariano]

Not sure what's going on there. You can work around the problem by setting debug=true which seems to work just fine, no issues. The error check looks like it's triggering even though there's nothing actually wrong.

[adrianVmariano]

I have hopefully/maybe fixed this without breaking something else. It appears that under some circumstances rounding errors results in a value that is supposed to be >=0 ending up less than zero, so I relaxed the test. It appears to work on your test case. The change appears in the PR.

[dan-p3rry]

That's excellent, thanks. I'm ignorant how the process goes, getting from a Pull Request to a downloadable executable. What's the usual schedule? (No rush, just want to understand.) Regards, Dan

…

On Mon, Oct 14, 2024 at 9:13 PM adrianVmariano ***@***.***> wrote: I have hopefully/maybe fixed this without breaking something else. It appears that under some circumstances rounding errors results in a value that is supposed to be >=0 ending up less than zero, so I relaxed the test. It appears to work on your test case. The change appears in the PR. — Reply to this email directly, view it on GitHub <#1488 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVJPTT35THMUY2R7KU3A26DZ3QQU5AVCNFSM6AAAAABPTBW4JKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJSGEYTQNJQGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[adrianVmariano]

It's a little random these days. Revar will merge the PR at some point, perhaps tonight, or maybe in a week. I think that when that happens you get an email that your issue was closed.