I just held a real strip up to my monitor and can see it quite different at the extremes, so yes I would be interested to see your minimum energy solution please Ronaldo. On 19 December 2017 at 22:19, nop head <nop.head@gmail.com> wrote: > Hi Ronaldo, > Thanks for your input. I tried dropping in your changes to my code but > didn't see any noticeable speed improvement. I think this is because I had > already made the length function faster by only using 100 segments instead > of 1000. I also calculate the target length to give the minimum z that is > allowed by adjusting the control points until it droops the correct amount. > > My code currently takes 20 seconds because I added the ribbon cable and > sweep each wire separately because they take different paths at the fold. I > also model the veroboard terminations including tracks, breaks and solder > menisci! I think the time for the Bezier calculation is swamped by 20 > sweeps. I used Frenet-Serret for the strip because it has two vertical > sections that the minimum angle solution doesn't like. I used minimum angle > for the cable because Frenet-Serret goes wild when the at the fold. > > Yes I think you are correct saying the optimum starting angle is not > straight down but I am not sure if that is worth changing. I still need to > see how accurate it is against a real strip. > > > ​ > > > > > > On 18 December 2017 at 12:23, Ronaldo Persiano <rcmpersiano@gmail.com> > wrote: > >> I have been struggling with this problem for a while. I will not go into >> the details of the energy minimizing problem here and will just address the >> problem of finding the Bezier arc with a given length, given its end points >> and its tangent directions at the endpoints. The function AdjustBezier() >> provided by Torleif is inefficient for this task requiring a lot of >> adjustment. >> >> The main idea of Torleif solution is to adjust the Bezier arc endpoints >> derivatives until the required length is attained. The adjustment is done >> by: >> >> function adjust1(p, r) = >> [ p[0], p[0]+(p[1]-p[0])*r, p[3]+(p[2]-p[3])*r , p[3] ]; >> >> >> where p is the incoming Bezier control points and r is the adjustment >> parameter. So, the problem is to find the parameter r such that: >> >> len3bz(adjust(p,r)) == length >> >> >> where len3bz() is the function that estimates a Bezier arc length. >> >> I have observed that the length of the Bezier arc is fairly linear with >> respect to the parameter r and the following code explores it: >> >> function AdjustBezier(p, l, eps=0.001, r1=10, r2=12, l1, l2)= >> let( l1 = l1!=undef? l1: len3bz(adjust1(p,r1), eps), >> l2 = l2!=undef? l2: len3bz(adjust1(p,r2), eps) ) >> abs(l1-l)<eps ? >> adjust1(p,r1) >> : >> let( r = r1 + (l-l1)*(r2-r1)/(l2-l1) ) >> abs(r-r1)<abs(r-r2) ? >> AdjustBezier(p, l, eps, r, r1, undef, l1) >> : >> AdjustBezier(p, l, eps, r, r2, undef, l2); >> >> >> This function requires very few steps compared with Torleif's one which >> is very lengthy when the solution is almost stretched. >> >> Next, I have considered the time consuming function len3bz(). I >> approached this by Bezier subdivision instead of a fixed sample of Bezier >> evaluations. The resulting code is a bit longer but it is more efficient. >> >> function len3bz(bz, eps=0.001) = >> let( l1 = polygonalLength(bz, ceil(-log(eps))), >> l2 = polygonalLength([for(i=[0:3:len(bz)-1]) bz[i]], >> ceil(-log(eps))) ) >> l1-l2<eps ? >> (l1+l2)/2 >> : >> len3bz(subdivBezier3(bz, 1), eps); >> >> function polygonalLength(p) = >> let( l = [for(i=[1:len(p)-1]) norm(p[i]-p[i-1]) ] ) >> l*[for(i=[0:len(l)-1]) 1]; >> >> function subdivBezier3(p, n=3) = >> n==0 ? >> p >> : >> subdivBezier3( concat([for(i=[0:3:len(p)-4], >> s=[_subdivB(p,i)], >> j=[0:len(s)-2] ) s[j] ], >> [p[len(p)-1] ] ), >> n-1); >> >> function _subdivB(p, from=0) = >> [ [1,0,0,0], >> [1/2,1/2,0,0], >> [1/4,1/2,1/4,0], >> [1/8,3/8, 3/8, 1/8], >> [0, 1/4,1/2,1/4], >> [0, 0, 1/2,1/2], >> [0, 0, 0, 1] ] >> * [p[from], p[from+1], p[from+2], p[from+3] ]; >> >> >> I have addressed the problem of finding the minimum energy Bezier arc >> too. I have a version that is reasonable fast now requiring between 1 to 2 >> sec for each step of an animation similar to nophead's one. I don't believe >> that material is of broad interest but anyone interested in it may contact >> me by PM. >> >> BTW, I think nophead could reduce the polypropylene strip strain by >> giving it a little slope in the table end instead of driving it vertically. >> >> >> 2017-12-07 10:22 GMT-02:00 nop head <nop.head@gmail.com>: >> >>> Yes I suspect the bend radius would be a bit bigger in real life, closer >>> to an arc. The cable is ribbon, so not stiff at all but I bend it around a >>> 0.8mm thick polypropylene strip to distribute the bending. It is the strip >>> I am trying to model. It works like a cable chain for ribbon but is a lot >>> more compact and cheaper. Without it ribbon tends to bend too much at the >>> attachment points. >>> >>> The model needs to predict the length to make the strip as that goes on >>> the BOM. The length should be as long as possible without hitting the >>> bottom as it would buckle if it did. Using Bezier my guess is it is a bit >>> shorter than it could be. If it is not too much that will be OK but if it >>> is grossly wrong then the strip is tighter than it needs to be so is not >>> good for cable life. >>> >>> When I get home I will mock it up and see if it is accurate enough. If >>> not I will try to work out a minimum energy solution using finite elements. >>> It is after all drawn with 100 finite elements so I can easily calculate >>> the bend at each joint. The tricky bit is moving the joints to minimise the >>> energy. >>> >>> On 7 December 2017 at 10:31, <arnholm@arnholm.org> wrote: >>> >>>> On 2017-12-05 23:01, nop head wrote: >>>> >>>>> Yes it is a bit tight, which is why I modelled it. The problem is it >>>>> needs to not hit the shelf below that covers the electronics. It only >>>>> cycles once per build so I think I will get away with it. I have used >>>>> ribbons on X and Y that move millions of times in a build. >>>>> >>>> >>>> Nice video, although the cable deformation is somewhat unrealistic. >>>> >>>> If knowing the true shape was critical, it would require non-linear >>>> finite element analysis. Someone mentioned a catenary, but this cable is >>>> much stiffer than a catenary (essentially no bending stiffness). The >>>> problem is quite similar to analyzing flexible risers used on the offshore >>>> industry. Non-negligible bending stiffness, large deformations, boundary >>>> conditions at the ends. >>>> >>>> Still the simplified approximation was quite ok for a demo. >>>> >>>> Carsten Arnholm >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >

As a long-time happy builder/user of a Mendel90, I must say I love seeing these sneak peeks at what you're cooking up next, and it continually impresses me how thorough you are with your OpenSCAD designs! Cheers, Len. On 20 December 2017 at 11:19, nop head <nop.head@gmail.com> wrote: > Hi Ronaldo, > Thanks for your input. I tried dropping in your changes to my code but > didn't see any noticeable speed improvement. I think this is because I had > already made the length function faster by only using 100 segments instead > of 1000. I also calculate the target length to give the minimum z that is > allowed by adjusting the control points until it droops the correct amount. > > My code currently takes 20 seconds because I added the ribbon cable and > sweep each wire separately because they take different paths at the fold. I > also model the veroboard terminations including tracks, breaks and solder > menisci! I think the time for the Bezier calculation is swamped by 20 > sweeps. I used Frenet-Serret for the strip because it has two vertical > sections that the minimum angle solution doesn't like. I used minimum angle > for the cable because Frenet-Serret goes wild when the at the fold. > > Yes I think you are correct saying the optimum starting angle is not > straight down but I am not sure if that is worth changing. I still need to > see how accurate it is against a real strip. > > > ​ > > > > > > On 18 December 2017 at 12:23, Ronaldo Persiano <rcmpersiano@gmail.com> > wrote: > >> I have been struggling with this problem for a while. I will not go into >> the details of the energy minimizing problem here and will just address the >> problem of finding the Bezier arc with a given length, given its end points >> and its tangent directions at the endpoints. The function AdjustBezier() >> provided by Torleif is inefficient for this task requiring a lot of >> adjustment. >> >> The main idea of Torleif solution is to adjust the Bezier arc endpoints >> derivatives until the required length is attained. The adjustment is done >> by: >> >> function adjust1(p, r) = >> [ p[0], p[0]+(p[1]-p[0])*r, p[3]+(p[2]-p[3])*r , p[3] ]; >> >> >> where p is the incoming Bezier control points and r is the adjustment >> parameter. So, the problem is to find the parameter r such that: >> >> len3bz(adjust(p,r)) == length >> >> >> where len3bz() is the function that estimates a Bezier arc length. >> >> I have observed that the length of the Bezier arc is fairly linear with >> respect to the parameter r and the following code explores it: >> >> function AdjustBezier(p, l, eps=0.001, r1=10, r2=12, l1, l2)= >> let( l1 = l1!=undef? l1: len3bz(adjust1(p,r1), eps), >> l2 = l2!=undef? l2: len3bz(adjust1(p,r2), eps) ) >> abs(l1-l)<eps ? >> adjust1(p,r1) >> : >> let( r = r1 + (l-l1)*(r2-r1)/(l2-l1) ) >> abs(r-r1)<abs(r-r2) ? >> AdjustBezier(p, l, eps, r, r1, undef, l1) >> : >> AdjustBezier(p, l, eps, r, r2, undef, l2); >> >> >> This function requires very few steps compared with Torleif's one which >> is very lengthy when the solution is almost stretched. >> >> Next, I have considered the time consuming function len3bz(). I >> approached this by Bezier subdivision instead of a fixed sample of Bezier >> evaluations. The resulting code is a bit longer but it is more efficient. >> >> function len3bz(bz, eps=0.001) = >> let( l1 = polygonalLength(bz, ceil(-log(eps))), >> l2 = polygonalLength([for(i=[0:3:len(bz)-1]) bz[i]], >> ceil(-log(eps))) ) >> l1-l2<eps ? >> (l1+l2)/2 >> : >> len3bz(subdivBezier3(bz, 1), eps); >> >> function polygonalLength(p) = >> let( l = [for(i=[1:len(p)-1]) norm(p[i]-p[i-1]) ] ) >> l*[for(i=[0:len(l)-1]) 1]; >> >> function subdivBezier3(p, n=3) = >> n==0 ? >> p >> : >> subdivBezier3( concat([for(i=[0:3:len(p)-4], >> s=[_subdivB(p,i)], >> j=[0:len(s)-2] ) s[j] ], >> [p[len(p)-1] ] ), >> n-1); >> >> function _subdivB(p, from=0) = >> [ [1,0,0,0], >> [1/2,1/2,0,0], >> [1/4,1/2,1/4,0], >> [1/8,3/8, 3/8, 1/8], >> [0, 1/4,1/2,1/4], >> [0, 0, 1/2,1/2], >> [0, 0, 0, 1] ] >> * [p[from], p[from+1], p[from+2], p[from+3] ]; >> >> >> I have addressed the problem of finding the minimum energy Bezier arc >> too. I have a version that is reasonable fast now requiring between 1 to 2 >> sec for each step of an animation similar to nophead's one. I don't believe >> that material is of broad interest but anyone interested in it may contact >> me by PM. >> >> BTW, I think nophead could reduce the polypropylene strip strain by >> giving it a little slope in the table end instead of driving it vertically. >> >> >> 2017-12-07 10:22 GMT-02:00 nop head <nop.head@gmail.com>: >> >>> Yes I suspect the bend radius would be a bit bigger in real life, closer >>> to an arc. The cable is ribbon, so not stiff at all but I bend it around a >>> 0.8mm thick polypropylene strip to distribute the bending. It is the strip >>> I am trying to model. It works like a cable chain for ribbon but is a lot >>> more compact and cheaper. Without it ribbon tends to bend too much at the >>> attachment points. >>> >>> The model needs to predict the length to make the strip as that goes on >>> the BOM. The length should be as long as possible without hitting the >>> bottom as it would buckle if it did. Using Bezier my guess is it is a bit >>> shorter than it could be. If it is not too much that will be OK but if it >>> is grossly wrong then the strip is tighter than it needs to be so is not >>> good for cable life. >>> >>> When I get home I will mock it up and see if it is accurate enough. If >>> not I will try to work out a minimum energy solution using finite elements. >>> It is after all drawn with 100 finite elements so I can easily calculate >>> the bend at each joint. The tricky bit is moving the joints to minimise the >>> energy. >>> >>> On 7 December 2017 at 10:31, <arnholm@arnholm.org> wrote: >>> >>>> On 2017-12-05 23:01, nop head wrote: >>>> >>>>> Yes it is a bit tight, which is why I modelled it. The problem is it >>>>> needs to not hit the shelf below that covers the electronics. It only >>>>> cycles once per build so I think I will get away with it. I have used >>>>> ribbons on X and Y that move millions of times in a build. >>>>> >>>> >>>> Nice video, although the cable deformation is somewhat unrealistic. >>>> >>>> If knowing the true shape was critical, it would require non-linear >>>> finite element analysis. Someone mentioned a catenary, but this cable is >>>> much stiffer than a catenary (essentially no bending stiffness). The >>>> problem is quite similar to analyzing flexible risers used on the offshore >>>> industry. Non-negligible bending stiffness, large deformations, boundary >>>> conditions at the ends. >>>> >>>> Still the simplified approximation was quite ok for a demo. >>>> >>>> Carsten Arnholm >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Good to see foldback clips are still state-of-the-art for printing plate attachment. ----- Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- Sent from: http://forum.openscad.org/

nah print on masking tape, with gobs of that holding down my plate who needs clips! On 20/12/17 04:30, MichaelAtOz wrote: > foldback clips

Unfortunately, I am away home and haven't took my notebook with me. You will have to wait till after Christmas... I can tell you the general principles, though. The energy expression of a curve was taken proportional to the integral of its second parametric derivative. Using Maxima, I found the energy of a cubic arc may be computed by: d0*d0 + d0*d1 + d1*d1 where d0 and d1 are the second parametric derivatives at the ends of the arc. In order to change the arc to minimize its energy, I have used the following adjustment: function adjust2(bz, s) = [ [ bz[0], bz[0] + 2*(1-s)*(b[1]-bz[0]), bz[3] + 2*s*(b[2]-bz[3]), bz[3] ]; where s is a real parameter in [0,1]. The parameter s changes the balance between the two end derivatives of the arc. In special, adjust2(bz, 0.5) == bz. Plotting the energy of an adjusted arc as a function of s in [0,1], I found that it has no other local minimum besides the global minimum. The energy minimizing process is a recursive algorithm that starts with an interval of s values (s0, s1) that contains the minimum s, finds an approximation of the minimum and a narrower interval to recur. To find an approximation, I interpolate a quadratic polynomial to the points s0, (s0+s1)/2 and s1 and find its minimum. For each s whose energy is needed, the arc is adjusted to the proper length by AdujstBezier. 2017-12-19 20:39 GMT-02:00 nop head <nop.head@gmail.com>: > I just held a real strip up to my monitor and can see it quite different > at the extremes, so yes I would be interested to see your minimum energy > solution please Ronaldo. > > On 19 December 2017 at 22:19, nop head <nop.head@gmail.com> wrote: > >> Hi Ronaldo, >> Thanks for your input. I tried dropping in your changes to my code but >> didn't see any noticeable speed improvement. I think this is because I had >> already made the length function faster by only using 100 segments instead >> of 1000. I also calculate the target length to give the minimum z that is >> allowed by adjusting the control points until it droops the correct amount. >> >> My code currently takes 20 seconds because I added the ribbon cable and >> sweep each wire separately because they take different paths at the fold. I >> also model the veroboard terminations including tracks, breaks and solder >> menisci! I think the time for the Bezier calculation is swamped by 20 >> sweeps. I used Frenet-Serret for the strip because it has two vertical >> sections that the minimum angle solution doesn't like. I used minimum angle >> for the cable because Frenet-Serret goes wild when the at the fold. >> >> Yes I think you are correct saying the optimum starting angle is not >> straight down but I am not sure if that is worth changing. I still need to >> see how accurate it is against a real strip. >> >> >> ​ >> >> >> >> >> >> On 18 December 2017 at 12:23, Ronaldo Persiano <rcmpersiano@gmail.com> >> wrote: >> >>> I have been struggling with this problem for a while. I will not go into >>> the details of the energy minimizing problem here and will just address the >>> problem of finding the Bezier arc with a given length, given its end points >>> and its tangent directions at the endpoints. The function AdjustBezier() >>> provided by Torleif is inefficient for this task requiring a lot of >>> adjustment. >>> >>> The main idea of Torleif solution is to adjust the Bezier arc endpoints >>> derivatives until the required length is attained. The adjustment is done >>> by: >>> >>> function adjust1(p, r) = >>> [ p[0], p[0]+(p[1]-p[0])*r, p[3]+(p[2]-p[3])*r , p[3] ]; >>> >>> >>> where p is the incoming Bezier control points and r is the adjustment >>> parameter. So, the problem is to find the parameter r such that: >>> >>> len3bz(adjust(p,r)) == length >>> >>> >>> where len3bz() is the function that estimates a Bezier arc length. >>> >>> I have observed that the length of the Bezier arc is fairly linear with >>> respect to the parameter r and the following code explores it: >>> >>> function AdjustBezier(p, l, eps=0.001, r1=10, r2=12, l1, l2)= >>> let( l1 = l1!=undef? l1: len3bz(adjust1(p,r1), eps), >>> l2 = l2!=undef? l2: len3bz(adjust1(p,r2), eps) ) >>> abs(l1-l)<eps ? >>> adjust1(p,r1) >>> : >>> let( r = r1 + (l-l1)*(r2-r1)/(l2-l1) ) >>> abs(r-r1)<abs(r-r2) ? >>> AdjustBezier(p, l, eps, r, r1, undef, l1) >>> : >>> AdjustBezier(p, l, eps, r, r2, undef, l2); >>> >>> >>> This function requires very few steps compared with Torleif's one which >>> is very lengthy when the solution is almost stretched. >>> >>> Next, I have considered the time consuming function len3bz(). I >>> approached this by Bezier subdivision instead of a fixed sample of Bezier >>> evaluations. The resulting code is a bit longer but it is more efficient. >>> >>> function len3bz(bz, eps=0.001) = >>> let( l1 = polygonalLength(bz, ceil(-log(eps))), >>> l2 = polygonalLength([for(i=[0:3:len(bz)-1]) bz[i]], >>> ceil(-log(eps))) ) >>> l1-l2<eps ? >>> (l1+l2)/2 >>> : >>> len3bz(subdivBezier3(bz, 1), eps); >>> >>> function polygonalLength(p) = >>> let( l = [for(i=[1:len(p)-1]) norm(p[i]-p[i-1]) ] ) >>> l*[for(i=[0:len(l)-1]) 1]; >>> >>> function subdivBezier3(p, n=3) = >>> n==0 ? >>> p >>> : >>> subdivBezier3( concat([for(i=[0:3:len(p)-4], >>> s=[_subdivB(p,i)], >>> j=[0:len(s)-2] ) s[j] ], >>> [p[len(p)-1] ] ), >>> n-1); >>> >>> function _subdivB(p, from=0) = >>> [ [1,0,0,0], >>> [1/2,1/2,0,0], >>> [1/4,1/2,1/4,0], >>> [1/8,3/8, 3/8, 1/8], >>> [0, 1/4,1/2,1/4], >>> [0, 0, 1/2,1/2], >>> [0, 0, 0, 1] ] >>> * [p[from], p[from+1], p[from+2], p[from+3] ]; >>> >>> >>> I have addressed the problem of finding the minimum energy Bezier arc >>> too. I have a version that is reasonable fast now requiring between 1 to 2 >>> sec for each step of an animation similar to nophead's one. I don't believe >>> that material is of broad interest but anyone interested in it may contact >>> me by PM. >>> >>> BTW, I think nophead could reduce the polypropylene strip strain by >>> giving it a little slope in the table end instead of driving it vertically. >>> >>> >>> 2017-12-07 10:22 GMT-02:00 nop head <nop.head@gmail.com>: >>> >>>> Yes I suspect the bend radius would be a bit bigger in real life, >>>> closer to an arc. The cable is ribbon, so not stiff at all but I bend it >>>> around a 0.8mm thick polypropylene strip to distribute the bending. It is >>>> the strip I am trying to model. It works like a cable chain for ribbon but >>>> is a lot more compact and cheaper. Without it ribbon tends to bend too much >>>> at the attachment points. >>>> >>>> The model needs to predict the length to make the strip as that goes on >>>> the BOM. The length should be as long as possible without hitting the >>>> bottom as it would buckle if it did. Using Bezier my guess is it is a bit >>>> shorter than it could be. If it is not too much that will be OK but if it >>>> is grossly wrong then the strip is tighter than it needs to be so is not >>>> good for cable life. >>>> >>>> When I get home I will mock it up and see if it is accurate enough. If >>>> not I will try to work out a minimum energy solution using finite elements. >>>> It is after all drawn with 100 finite elements so I can easily calculate >>>> the bend at each joint. The tricky bit is moving the joints to minimise the >>>> energy. >>>> >>>> On 7 December 2017 at 10:31, <arnholm@arnholm.org> wrote: >>>> >>>>> On 2017-12-05 23:01, nop head wrote: >>>>> >>>>>> Yes it is a bit tight, which is why I modelled it. The problem is it >>>>>> needs to not hit the shelf below that covers the electronics. It only >>>>>> cycles once per build so I think I will get away with it. I have used >>>>>> ribbons on X and Y that move millions of times in a build. >>>>>> >>>>> >>>>> Nice video, although the cable deformation is somewhat unrealistic. >>>>> >>>>> If knowing the true shape was critical, it would require non-linear >>>>> finite element analysis. Someone mentioned a catenary, but this cable is >>>>> much stiffer than a catenary (essentially no bending stiffness). The >>>>> problem is quite similar to analyzing flexible risers used on the offshore >>>>> industry. Non-negligible bending stiffness, large deformations, boundary >>>>> conditions at the ends. >>>>> >>>>> Still the simplified approximation was quite ok for a demo. >>>>> >>>>> Carsten Arnholm >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

2017-12-19 20:19 GMT-02:00 nop head <nop.head@gmail.com>: > I used Frenet-Serret for the strip because it has two vertical sections > that the minimum angle solution doesn't like. I used minimum angle for the > cable because Frenet-Serret goes wild when the at the fold. > > ​Yes, the original Oskar Linde´s sweep may generate very wild twists in some vertical path ​segments. You may find useful a version I wrote based on Oskar Linde's suggestions that have never being included in his original code. It can be found in https://github.com/RonaldoCMP/list-comprehension-demos/blob/master/sweep.scad. It works fine and better than Frenet frames.

Thanks I will have a dabble with that if I have time over Christmas. I have been working on this project for more than a year and tend to do it while on holiday so there really is no urgency! On 20 December 2017 at 18:02, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: > 2017-12-19 20:19 GMT-02:00 nop head <nop.head@gmail.com>: > >> I used Frenet-Serret for the strip because it has two vertical sections >> that the minimum angle solution doesn't like. I used minimum angle for the >> cable because Frenet-Serret goes wild when the at the fold. >> >> > ​Yes, the original Oskar Linde´s sweep may generate very wild twists in > some vertical path ​segments. You may find useful a version I wrote based > on Oskar Linde's suggestions that have never being included in his original > code. It can be found in https://github.com/RonaldoCMP/list-comprehension- > demos/blob/master/sweep.scad. It works fine and better than Frenet frames. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

I ran into that issue with vertical sections of my sweeps as well. I fixed it by changing my code to use quaternions instead of Euler angles. - Revar > On Dec 20, 2017, at 10:12 AM, nop head <nop.head@gmail.com> wrote: > > Thanks I will have a dabble with that if I have time over Christmas. I have been working on this project for more than a year and tend to do it while on holiday so there really is no urgency! > >> On 20 December 2017 at 18:02, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: >> 2017-12-19 20:19 GMT-02:00 nop head <nop.head@gmail.com>: >>> I used Frenet-Serret for the strip because it has two vertical sections that the minimum angle solution doesn't like. I used minimum angle for the cable because Frenet-Serret goes wild when the at the fold. >>> >> >> ​Yes, the original Oskar Linde´s sweep may generate very wild twists in some vertical path ​segments. You may find useful a version I wrote based on Oskar Linde's suggestions that have never being included in his original code. It can be found in https://github.com/RonaldoCMP/list-comprehension-demos/blob/master/sweep.scad. It works fine and better than Frenet frames. >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

The sweep.scad code doesn't compute rotations from angles. The rotation unstability on vertical segments results from computing the section rotations globally. The alternative code instead computes the global section rotation by composing small local rotations from one path point to the next. 2017-12-20 17:53 GMT-02:00 Revar Desmera <revarbat@gmail.com>: > I ran into that issue with vertical sections of my sweeps as well. I fixed > it by changing my code to use quaternions instead of Euler angles. > > - Revar >

>The energy expression of a curve was taken proportional to the integral of its second parametric derivative I don't think this is right. I think the energy is proportional to the integral of the square of curvature. This is because the potential energy in a spring is a square law due to the force increasing as you bend it. Also I think curvature is second derivative with respect to arc length, not the parameter. On 20 December 2017 at 20:07, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: > The sweep.scad code doesn't compute rotations from angles. The rotation > unstability on vertical segments results from computing the section > rotations globally. The alternative code instead computes the global > section rotation by composing small local rotations from one path point to > the next. > > 2017-12-20 17:53 GMT-02:00 Revar Desmera <revarbat@gmail.com>: > >> I ran into that issue with vertical sections of my sweeps as well. I >> fixed it by changing my code to use quaternions instead of Euler angles. >> >> - Revar >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >