AM
Adrian Mariano
Sat, Feb 5, 2022 5:19 PM
If the requested radii do not fit, the answer is simple: display an error
and let the user fix it. I know that in the Round-Anything library there
is a complex scheme for adjusting the roundovers so they fit, but I think
it's better to fail in that case than to do something possibly somewhat
mysterious. It leads to confusion, if for example I decrease a radius and
nothing happens because the code already decreased it internally. The
only way to completely avoid the "radii fit" problem is to define the radii
as extra sections, which is how BOSL2's turtle() function handles rounded
corners. This can be hard to use in practice, though, because roundings
then add an offset that it's complicated to understand.
I suspect that in the wire-run scenario you will not be trying to turn
corners that are shorter than the length of the wire runs, so this is
really a non-issue for that application.
On Sat, Feb 5, 2022 at 12:10 PM Sanjeev Prabhakar sprabhakar2006@gmail.com
wrote:
The problem can happen when the length of the line is less than the radius
defined at 2 points (I mean r*tan(theta/2), where theta is the arc angle).
Then you have to decide to either reduce the radius or increase the length
(most likely the radius needs to be reduced)
. This is not a simple thing to do considering various lines and radiuses.
On Sat, 5 Feb 2022 at 22:30, Adrian Mariano avm4@cornell.edu wrote:
I don't understand the conflict. This is how the BOSL2 wiring module
works. You specify a list of points defining the wire run assuming wires
make sharp bends and you give a radius for the corners. So wires go from
p[0] to p[1] to p[2] to p[3], ..., p[N]. And then you have radii at p[1],
p[2], p[3], up to P[N-1].
On Sat, Feb 5, 2022 at 11:44 AM nop head nop.head@gmail.com wrote:
Yes I considered that but it creates conflicts to specify both the end
points and the radii. Perhaps start, end, radius, next end radius, next
end radius, etc works.
On Sat, 5 Feb 2022 at 13:55, Adrian Mariano avm4@cornell.edu wrote:
Why not specify wire paths by giving a list of points ignoring the
curves and then a radius for curves (or list of radii if you want it to
vary). It's easy to write some code to add the curves to the path without
any crazy trial and error.
On Sat, Feb 5, 2022 at 4:28 AM nop head nop.head@gmail.com wrote:
Yes I use arc_points for generating cable runs but I find it difficult
to get the rotate parameter correct myself, as I do all multi axis
rotates in OpenSCAD and often resort to trial and error. Sometimes in
desperation I work out the transformation matrix by hand as I know I want z
= -x, etc, and then pass the matrix of 1s and -1s to euler() to give me the
rotation parameters. I did that while designing this.
[image: image.png]
I am currently working on an easier way to specify a wire path, with
just one angle around the axis of the wire and an optional second one to
specify a bend that is not 90 degrees. Then I will have a list of those
separated by lengths of the straight sections.
On Sat, 5 Feb 2022 at 08:36, Sanjeev Prabhakar <
sprabhakar2006@gmail.com> wrote:
following function can generate arc points as well
function
arc(radius,ang1=0,ang2=355,cp=[0,0],s=20)=[for(i=[ang1:(ang2-ang1)/s:ang2])cp+[radiuscos(i),radiussin(i)]];
where:
radius: Radius of the arc
ang1: start angle referenced from positive x-axis
ang2: ending of arc angle again referenced from positive x-axis
s: number of segments required in the arc
On Sat, 5 Feb 2022 at 10:10, Father Horton fatherhorton@gmail.com
wrote:
I'm hoping to use the sweep function, but along the way I need to
use arc_points and it's not clear to me what the arguments do, even after
looking at the source..
r = radius of the arc
a = ?
al = arc length in degrees?
arc_points(r, a = [90, 0, 180], al = 90)
Any insight?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
If the requested radii do not fit, the answer is simple: display an error
and let the user fix it. I know that in the Round-Anything library there
is a complex scheme for adjusting the roundovers so they fit, but I think
it's better to fail in that case than to do something possibly somewhat
mysterious. It leads to confusion, if for example I decrease a radius and
nothing happens because the code already decreased it internally. The
only way to completely avoid the "radii fit" problem is to define the radii
as extra sections, which is how BOSL2's turtle() function handles rounded
corners. This can be hard to use in practice, though, because roundings
then add an offset that it's complicated to understand.
I suspect that in the wire-run scenario you will not be trying to turn
corners that are shorter than the length of the wire runs, so this is
really a non-issue for that application.
On Sat, Feb 5, 2022 at 12:10 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com>
wrote:
> The problem can happen when the length of the line is less than the radius
> defined at 2 points (I mean r*tan(theta/2), where theta is the arc angle).
> Then you have to decide to either reduce the radius or increase the length
> (most likely the radius needs to be reduced)
> . This is not a simple thing to do considering various lines and radiuses.
>
> On Sat, 5 Feb 2022 at 22:30, Adrian Mariano <avm4@cornell.edu> wrote:
>
>> I don't understand the conflict. This is how the BOSL2 wiring module
>> works. You specify a list of points defining the wire run assuming wires
>> make sharp bends and you give a radius for the corners. So wires go from
>> p[0] to p[1] to p[2] to p[3], ..., p[N]. And then you have radii at p[1],
>> p[2], p[3], up to P[N-1].
>>
>> On Sat, Feb 5, 2022 at 11:44 AM nop head <nop.head@gmail.com> wrote:
>>
>>> Yes I considered that but it creates conflicts to specify both the end
>>> points and the radii. Perhaps start, end, radius, next end radius, next
>>> end radius, etc works.
>>>
>>> On Sat, 5 Feb 2022 at 13:55, Adrian Mariano <avm4@cornell.edu> wrote:
>>>
>>>> Why not specify wire paths by giving a list of points ignoring the
>>>> curves and then a radius for curves (or list of radii if you want it to
>>>> vary). It's easy to write some code to add the curves to the path without
>>>> any crazy trial and error.
>>>>
>>>> On Sat, Feb 5, 2022 at 4:28 AM nop head <nop.head@gmail.com> wrote:
>>>>
>>>>> Yes I use arc_points for generating cable runs but I find it difficult
>>>>> to get the rotate parameter correct myself, as I do all multi axis
>>>>> rotates in OpenSCAD and often resort to trial and error. Sometimes in
>>>>> desperation I work out the transformation matrix by hand as I know I want z
>>>>> = -x, etc, and then pass the matrix of 1s and -1s to euler() to give me the
>>>>> rotation parameters. I did that while designing this.
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> I am currently working on an easier way to specify a wire path, with
>>>>> just one angle around the axis of the wire and an optional second one to
>>>>> specify a bend that is not 90 degrees. Then I will have a list of those
>>>>> separated by lengths of the straight sections.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, 5 Feb 2022 at 08:36, Sanjeev Prabhakar <
>>>>> sprabhakar2006@gmail.com> wrote:
>>>>>
>>>>>> following function can generate arc points as well
>>>>>>
>>>>>> function
>>>>>> arc(radius,ang1=0,ang2=355,cp=[0,0],s=20)=[for(i=[ang1:(ang2-ang1)/s:ang2])cp+[radius*cos(i),radius*sin(i)]];
>>>>>>
>>>>>> where:
>>>>>> radius: Radius of the arc
>>>>>> ang1: start angle referenced from positive x-axis
>>>>>> ang2: ending of arc angle again referenced from positive x-axis
>>>>>> s: number of segments required in the arc
>>>>>>
>>>>>>
>>>>>> On Sat, 5 Feb 2022 at 10:10, Father Horton <fatherhorton@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm hoping to use the sweep function, but along the way I need to
>>>>>>> use arc_points and it's not clear to me what the arguments do, even after
>>>>>>> looking at the source..
>>>>>>>
>>>>>>> r = radius of the arc
>>>>>>> a = ?
>>>>>>> al = arc length in degrees?
>>>>>>>
>>>>>>> arc_points(r, a = [90, 0, 180], al = 90)
>>>>>>>
>>>>>>> Any insight?
>>>>>>> _______________________________________________
>>>>>>> OpenSCAD mailing list
>>>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenSCAD mailing list
>>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>>
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
NH
nop head
Sat, Feb 5, 2022 5:36 PM
I deal with each conductor of a ribbon separately as each conductor bends
at a different point in a fold and some end at different points as well.
I.e. you might have two conductors splay and stop at a switch and the rest
continue on.
Yes a list of imaginary sharp vertices and radii makes sense.
On Sat, 5 Feb 2022 at 17:26, jon jon@jonbondy.com wrote:
In that situation, could the library cause an error, forcing the caller to
fix the parameters? This would work fine if the call was generated by a
human, but if the call was deep in a library that thought it was creating
reasonable parameters, then things could get complex. Well. They already
would be complex.
On 2/5/2022 12:09 PM, Sanjeev Prabhakar wrote:
The problem can happen when the length of the line is less than the radius
defined at 2 points (I mean r*tan(theta/2), where theta is the arc angle).
Then you have to decide to either reduce the radius or increase the length
(most likely the radius needs to be reduced)
. This is not a simple thing to do considering various lines and radiuses.
On Sat, 5 Feb 2022 at 22:30, Adrian Mariano avm4@cornell.edu wrote:
I don't understand the conflict. This is how the BOSL2 wiring module
works. You specify a list of points defining the wire run assuming wires
make sharp bends and you give a radius for the corners. So wires go from
p[0] to p[1] to p[2] to p[3], ..., p[N]. And then you have radii at p[1],
p[2], p[3], up to P[N-1].
On Sat, Feb 5, 2022 at 11:44 AM nop head nop.head@gmail.com wrote:
Yes I considered that but it creates conflicts to specify both the end
points and the radii. Perhaps start, end, radius, next end radius, next
end radius, etc works.
I deal with each conductor of a ribbon separately as each conductor bends
at a different point in a fold and some end at different points as well.
I.e. you might have two conductors splay and stop at a switch and the rest
continue on.
Yes a list of imaginary sharp vertices and radii makes sense.
On Sat, 5 Feb 2022 at 17:26, jon <jon@jonbondy.com> wrote:
> In that situation, could the library cause an error, forcing the caller to
> fix the parameters? This would work fine if the call was generated by a
> human, but if the call was deep in a library that thought it was creating
> reasonable parameters, then things could get complex. Well. They already
> would be complex.
> On 2/5/2022 12:09 PM, Sanjeev Prabhakar wrote:
>
> The problem can happen when the length of the line is less than the radius
> defined at 2 points (I mean r*tan(theta/2), where theta is the arc angle).
> Then you have to decide to either reduce the radius or increase the length
> (most likely the radius needs to be reduced)
> . This is not a simple thing to do considering various lines and radiuses.
>
> On Sat, 5 Feb 2022 at 22:30, Adrian Mariano <avm4@cornell.edu> wrote:
>
>> I don't understand the conflict. This is how the BOSL2 wiring module
>> works. You specify a list of points defining the wire run assuming wires
>> make sharp bends and you give a radius for the corners. So wires go from
>> p[0] to p[1] to p[2] to p[3], ..., p[N]. And then you have radii at p[1],
>> p[2], p[3], up to P[N-1].
>>
>> On Sat, Feb 5, 2022 at 11:44 AM nop head <nop.head@gmail.com> wrote:
>>
>>> Yes I considered that but it creates conflicts to specify both the end
>>> points and the radii. Perhaps start, end, radius, next end radius, next
>>> end radius, etc works.
>>>
>>> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
GH
gene heskett
Sat, Feb 5, 2022 6:15 PM
On Saturday, February 5, 2022 12:09:46 PM EST Sanjeev Prabhakar wrote:
The problem can happen when the length of the line is less than the
radius defined at 2 points (I mean r*tan(theta/2), where theta is the
arc angle). Then you have to decide to either reduce the radius or
increase the length (most likely the radius needs to be reduced)
. This is not a simple thing to do considering various lines and
radiuses.
Agreed, and speaking as a CET with experience in broadcasting at up to 30
some gigahertz, its not even that simple because when considering the
cross over at min radius, implied by this graphic, putting the folded
over ribbon cable that close to itself, will have measureable effects on
its characteristic impedance you can easily see on the time domain
reflectometer. If you have to tie that sort of knots in the cable,
minimum spacing to reduce that effect is going to be 3 or 4 times the
thickness of the insulation to maintain anything resembling the normal
ribbin cable impedance of approximately 120 ohms. Otherwise to paraphrase
an observation of the TDR waveform, its going to be lumpy, with extreme
cases ringing like the liberty bell.
Your chances of shipping error free data under those conditions aren't
100%. You would be far better off to checkout stacked, printed
microstrips, so your mounting could be suitably spaced, and would be
stiff enough to stay that way. Even individual runs of balanced cat6
could beat the ribbon cable by quite a large margin just because its
balanced AND twisted. There your cost is labor to assemble it, and the
baluns at both ends. The baluns are simple if you investigate two hole
ferrit beads and wind your own.
I don't understand the conflict. This is how the BOSL2 wiring module
works. You specify a list of points defining the wire run assuming
wires make sharp bends and you give a radius for the corners. So
wires go from p[0] to p[1] to p[2] to p[3], ..., p[N]. And then you
have radii at p[1], p[2], p[3], up to P[N-1].
On Sat, Feb 5, 2022 at 11:44 AM nop head nop.head@gmail.com wrote:
Yes I considered that but it creates conflicts to specify both the
end
points and the radii. Perhaps start, end, radius, next end radius,
next end radius, etc works.
On Sat, 5 Feb 2022 at 13:55, Adrian Mariano avm4@cornell.edu
Why not specify wire paths by giving a list of points ignoring the
curves and then a radius for curves (or list of radii if you want
it to vary). It's easy to write some code to add the curves to
the path without any crazy trial and error.
On Sat, Feb 5, 2022 at 4:28 AM nop head nop.head@gmail.com wrote:
Yes I use arc_points for generating cable runs but I find it
difficult
to get the rotate parameter correct myself, as I do all multi axis
rotates in OpenSCAD and often resort to trial and error. Sometimes
in
desperation I work out the transformation matrix by hand as I know
I want z = -x, etc, and then pass the matrix of 1s and -1s to
euler() to give me the rotation parameters. I did that while
designing this.
[image: image.png]
I am currently working on an easier way to specify a wire path,
with
just one angle around the axis of the wire and an optional second
one to specify a bend that is not 90 degrees. Then I will have a
list of those separated by lengths of the straight sections.
On Sat, 5 Feb 2022 at 08:36, Sanjeev Prabhakar <
sprabhakar2006@gmail.com> wrote:
following function can generate arc points as well
function
arc(radius,ang1=0,ang2=355,cp=[0,0],s=20)=[for(i=[ang1:(ang2-ang1
)/s:ang2])cp+[radiuscos(i),radiussin(i)]];
where:
radius: Radius of the arc
ang1: start angle referenced from positive x-axis
ang2: ending of arc angle again referenced from positive x-axis
s: number of segments required in the arc
On Sat, 5 Feb 2022 at 10:10, Father Horton
fatherhorton@gmail.com
wrote:
I'm hoping to use the sweep function, but along the way I need
to use
arc_points and it's not clear to me what the arguments do, even
after
looking at the source..
r = radius of the arc
a = ?
al = arc length in degrees?
arc_points(r, a = [90, 0, 180], al = 90)
Any insight?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
On Saturday, February 5, 2022 12:09:46 PM EST Sanjeev Prabhakar wrote:
> The problem can happen when the length of the line is less than the
> radius defined at 2 points (I mean r*tan(theta/2), where theta is the
> arc angle). Then you have to decide to either reduce the radius or
> increase the length (most likely the radius needs to be reduced)
> . This is not a simple thing to do considering various lines and
> radiuses.
Agreed, and speaking as a CET with experience in broadcasting at up to 30
some gigahertz, its not even that simple because when considering the
cross over at min radius, implied by this graphic, putting the folded
over ribbon cable that close to itself, will have measureable effects on
its characteristic impedance you can easily see on the time domain
reflectometer. If you have to tie that sort of knots in the cable,
minimum spacing to reduce that effect is going to be 3 or 4 times the
thickness of the insulation to maintain anything resembling the normal
ribbin cable impedance of approximately 120 ohms. Otherwise to paraphrase
an observation of the TDR waveform, its going to be lumpy, with extreme
cases ringing like the liberty bell.
Your chances of shipping error free data under those conditions aren't
100%. You would be far better off to checkout stacked, printed
microstrips, so your mounting could be suitably spaced, and would be
stiff enough to stay that way. Even individual runs of balanced cat6
could beat the ribbon cable by quite a large margin just because its
balanced AND twisted. There your cost is labor to assemble it, and the
baluns at both ends. The baluns are simple if you investigate two hole
ferrit beads and wind your own.
> On Sat, 5 Feb 2022 at 22:30, Adrian Mariano <avm4@cornell.edu> wrote:
> > I don't understand the conflict. This is how the BOSL2 wiring module
> > works. You specify a list of points defining the wire run assuming
> > wires make sharp bends and you give a radius for the corners. So
> > wires go from p[0] to p[1] to p[2] to p[3], ..., p[N]. And then you
> > have radii at p[1], p[2], p[3], up to P[N-1].
> >
> > On Sat, Feb 5, 2022 at 11:44 AM nop head <nop.head@gmail.com> wrote:
> >> Yes I considered that but it creates conflicts to specify both the
> >> end
> >> points and the radii. Perhaps start, end, radius, next end radius,
> >> next end radius, etc works.
> >>
> >> On Sat, 5 Feb 2022 at 13:55, Adrian Mariano <avm4@cornell.edu>
wrote:
> >>> Why not specify wire paths by giving a list of points ignoring the
> >>> curves and then a radius for curves (or list of radii if you want
> >>> it to vary). It's easy to write some code to add the curves to
> >>> the path without any crazy trial and error.
> >>>
> >>> On Sat, Feb 5, 2022 at 4:28 AM nop head <nop.head@gmail.com> wrote:
> >>>> Yes I use arc_points for generating cable runs but I find it
> >>>> difficult
> >>>> to get the rotate parameter correct myself, as I do all multi axis
> >>>> rotates in OpenSCAD and often resort to trial and error. Sometimes
> >>>> in
> >>>> desperation I work out the transformation matrix by hand as I know
> >>>> I want z = -x, etc, and then pass the matrix of 1s and -1s to
> >>>> euler() to give me the rotation parameters. I did that while
> >>>> designing this.
> >>>>
> >>>> [image: image.png]
> >>>>
> >>>> I am currently working on an easier way to specify a wire path,
> >>>> with
> >>>> just one angle around the axis of the wire and an optional second
> >>>> one to specify a bend that is not 90 degrees. Then I will have a
> >>>> list of those separated by lengths of the straight sections.
> >>>>
> >>>>
> >>>>
> >>>> On Sat, 5 Feb 2022 at 08:36, Sanjeev Prabhakar <
> >>>>
> >>>> sprabhakar2006@gmail.com> wrote:
> >>>>> following function can generate arc points as well
> >>>>>
> >>>>> function
> >>>>> arc(radius,ang1=0,ang2=355,cp=[0,0],s=20)=[for(i=[ang1:(ang2-ang1
> >>>>> )/s:ang2])cp+[radius*cos(i),radius*sin(i)]];
> >>>>>
> >>>>> where:
> >>>>> radius: Radius of the arc
> >>>>> ang1: start angle referenced from positive x-axis
> >>>>> ang2: ending of arc angle again referenced from positive x-axis
> >>>>> s: number of segments required in the arc
> >>>>>
> >>>>>
> >>>>> On Sat, 5 Feb 2022 at 10:10, Father Horton
> >>>>> <fatherhorton@gmail.com>
> >>>>>
> >>>>> wrote:
> >>>>>> I'm hoping to use the sweep function, but along the way I need
> >>>>>> to use
> >>>>>> arc_points and it's not clear to me what the arguments do, even
> >>>>>> after
> >>>>>> looking at the source..
> >>>>>>
> >>>>>> r = radius of the arc
> >>>>>> a = ?
> >>>>>> al = arc length in degrees?
> >>>>>>
> >>>>>> arc_points(r, a = [90, 0, 180], al = 90)
> >>>>>>
> >>>>>> Any insight?
> >>>>>> _______________________________________________
> >>>>>> OpenSCAD mailing list
> >>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenSCAD mailing list
> >>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
> >>>>
> >>>> _______________________________________________
> >>>> OpenSCAD mailing list
> >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
> >>>
> >>> _______________________________________________
> >>> OpenSCAD mailing list
> >>> To unsubscribe send an email to discuss-leave@lists.openscad.org
> >>
> >> _______________________________________________
> >> OpenSCAD mailing list
> >> To unsubscribe send an email to discuss-leave@lists.openscad.org
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
