Jump to content
Bomber Online Forums

jim_s

Member
  • Content count

    117
  • Joined

  • Last visited

  • Days Won

    2

jim_s last won the day on January 31

jim_s had the most liked content!

About jim_s

  • Rank
    Rider Extraordinaire

Converted

  • Location
    VA, United States
  • Home Mountain/Resort?
    Snowshoe, WV
  • Occupation?
    Computer Geek
  • Current Boards in your Quiver
    Donek SL158, Donek MK
  • Current Boots Used?
    Burton Shadow
  • Current bindings and set-up?
    Burton Race Plate
  • Snowboarding since
    ICRC
  • Hardbooting since
    Day2

Recent Profile Visitors

283 profile views
  1. Another vid for a laugh

    @RyanKnapton - time for you to level-up on the pole planting!! :-)
  2. Yikes - weren't those TD base plates made of machined aluminum? Maybe I'm confused about what you're looking for, but if its what I think it is, a 3D printed part would be wholly unsuited for the task.
  3. Hardbooter wins Olympic ski race!

    I'm laughing so hard, I've literally got tears streaming down my face. This is the Best.Olympic.Moment.of.2018.
  4. Every alpine boarder I've ever met is probably diagnosable with an obsessive personality disorder, so just add OpenSCAD to your list... ;-) For those w/o access to a 3D printer, there are online services that you can use to print your customized model. Shapeways is probably the most well known, but also tends to be rather expensive. 3DHubs is a collection of local geeks with printers who will print things for a price, and tends to be the least expensive option. One of @erazz's plates, via Shapeways, comes out to be about $270 - probably not a great price proposition. The same plate printed via 3DHubs (in PETG material) should be around $40-$45 + a few dollars in shipping. (this price is for one plate, so a pair would be in the $80-$90 range + shipping, but shipping via 3DHubs is usually *very* reasonable.) Compared to what I understand is something in the $70-$80 range (+ shipping from Europe) for a stock set of power plates, you'd be paying the same basic price for a fully customized set printed to your own personal specifications (lift, cant, twist, thickness, width, length, etc), so even for those w/o a printer, its likely still a pretty good deal. (The take-home message here, though, is its worth your while to have a 3D printer, or to at least be on good terms with someone who does, LoL! :-)
  5. These look great! Nice job on the updated lightening holes, too! Sound like you're an OpenSCAD believer - its not the answer for everything, but its a great answer for a lot of things! :-) Its really frustrating that Thingiverse hasn't fixed the library problem w/ Customizer. For anyone wanting to try out @erazz's power plates, though, you can freely download OpenSCAD, download his .scad file from Thingiverse, and customize it and run it locally in OpenSCAD. Super pumped that this is all finding its way down into use in our sport!! Great job on all of this @erazz!!
  6. LoL - these are the casualties of my OpenSCAD efforts over the last week or so. (The sharp observer will see an F2 binding photobombing in the lower-left corner of the photo... :-) I've dredged up a lot of high school geometry that I had long ago forgotten, since taking up OpenSCAD. I have to admit, I really enjoy it, though. (I have to admit that there are times, however, it would be nice just to click something w/ the mouse, and have magic happen... :-) I completely cheated on the F2 shims - I render the main block, then diff out a second block that is resized down by 2 times the wall thickness. I also split that resized block into parts by diffing out cross pieces and the cylinders around the bolt holes, and minkowski those remaining pieces, which results in the nicely filleted corners when I diff that all out of the main block. (The resized block retains the proper top angle, so the roof of the cavity is a consistent thickness regardless of lift, cant and elevation.) I was pretty psyched when I kinda stumbled on that approach! With your twist and difference in size between top and bottom, you've definitely got a tougher job figuring out the volume for the cavity, but I bet its do-able. (Better get some more scratch paper out, though!) The other option might be to put cylinders in the corner areas, then hull those, then diff out that hull from the main block - might save on some math, and still get you a fair bit of volume savings he
  7. Not sure what you don't like about the holes, but it looks great to me! I suppose the other thing you could do is figure out the common volume between the top and bottom plates, then hollow that area out underneath (leaving some wall/roof thickness), leaving material around the screw holes, and a few webs spanning the length and width. (This is similar to what I did on the underside of the F2 pieces, but my job was simpler, as there was no twist, and the top and bottom are also the same size!) From the printing perspective, its probably not as much a lightening thing, as a time-and-materials-saving thing.
  8. Nice!! That came out looking super! I agree that the sides look perfectly fine - also important to bear in mind this will be buried beneath a binding. :-) Sounds like the angle issue won't really be an issue at all - its definitely happening at the outer envelope of what anyone would reasonably expect to generate, and it can be compensated for by setting a larger height param. (I like your approach to applying the height to the middle - that'l really help in figuring out the range of bolt lengths you need.) Yeah, things often (usually) don't come out quite as 'pretty' in OpenSCAD, but for me, aesthetics are typically low on the list of design priorities, and the easy ability to customize the resulting model - even by people who don't know OpenSCAD - is where it really shines. Additionally, my mind just is not of the visual CAD mindset - managing planes, dragging things around, etc, is just not a natural fit. (That having been said, I think I like Onshape best of the ones I've tried in a while...) Holler if you need any help on anything, but it looks like you've got it fully in hand - really nice work, and I bet you'll help a lot of people out with it!
  9. BTW, @erazz - there still seems to be a problem w/ the translation/rotation order - try setting a lift angle of 8 or more degrees, or a cant angle of 10 or more degrees. (These may be outside the range of any values that anyone would ever set this to, I don't know. Might be worth noting though, if its possible people might use such angels.) The original model doesn't seem to have this problem, but you noted there were some unanticipated induced angles in the original - so just a question of which approach fits the real-world need better. This is much of the fun of parametric design, eh? :-)
  10. false alarm post about smoother body - more work needs to be done <:-)
  11. Makes sense! You could potentially include the cant, lift and twist values in lettering on the top of the plate - I'm doing that on my F2 shims, and it definitely helps keep them straight, when you've printed a variety of them. I played around a bit with a slightly more conservative approach to the body construction last night - it doesn't really end up being any faster, but it does seem to provide more smoothness on the sides, for the same amount of time. I'll mess with it a little more this evening, and shoot you a version, if I get it working well. You may like it better, or you may not - the transition to the sides from the top and bottom plates aren't quite as organic looking. Turns out the Thingiverse Customizer has been having this library problem for a week or so (lots of posts on it on the Thingiverse forums) - hopefully they'll get it fixed soon!
  12. You're right, but there certainly is some beauty in smooth, organic curves. :-) 20 layers looks like a pretty good compromise, though - its pretty darned smooth, looks nice, and rendered for me (locally) in 4:40. (There's something up w/ Customizer on Thingiverse - when I try to run it there, it throws an error, saying it can't find libCGAL.so, which is the graphics library that does the full-on rendering. I'm assuming that somebody has already alerted Thingiverse, but it its not fixed in the AM, I'll try to figure out how to let them know, just in case.) Ooh, good find - Thanks!!! I definitely had not noticed that - really glad you pointed that out, as I'm likely to use that approach again sometime, so will be sure to pay better attention to that order. Your plates look great - I'm impressed with how fast you've jumped into OpenSCAD and gotten a really nice result out of it! (You need to make your little arrow on top, though - that looks really cool. :-) If I understand the binding setup correctly, you run the bolt through the binding, then through this plate - if that's correct, countersinking the top of the screw holes isn't important from a screw head perspective, but from a 'getting the daggone bolt to go into the hole' perspective, it might be helpful. You could just diff out a little inverted cone around the top edges, such as I've done here: (its a kludge of an attempt, that I just threw together to illustrate, so I'm embarrassed to even post the code as it currently is, LoL :-)
  13. Ok, so, I was a bit irresponsible in how I handled the sub-plates (ie, that created by the component_plates() module), as well as with $fn values - as I noted, I did minimal testing on the little demo - I should have worked things through further, and optimized them more. As a little background, OpenSCAD uses two different engines for the 'preview' and the actual 'render' operations. (Preview being what you see when you hit 'F5' or the '>>' button on the screen. Render being when you hit 'F6', or the hourglass or 'STL' button on the screen.) The preview engine is fast and dirty, and skips some details along the way, to produce decent output as quickly as it can. (terms like 'fast', 'quick' and 'time' frequently have somewhat dubious meanings in OpenSCAD, under the best of conditions...) The full-on render is much more detailed and thorough, so things that appear in a reasonable time in the preview mode, can sometimes take inordinate amounts of time in the full-on render mode, as you've seen. Some common ways of reducing render time are to #1 reduce the complexity of the model, and #2 to reduce the number of faces that things like curves and spheres require - this can be particularly critical when using the minkowski() operator. I tromped all over item #1 - in muddy boots - in how I built up the body using the sub-plates - consider that each sub-plate is 2*end_rad thick, and I'm stacking 'steps' number of them together to make up the height of the body, when in reality, I really only need height/(2*end_rad) of them to do the job - so, there's a LOT of stuff being rendered there that doesn't really need to be rendered - its just all overlapping over/inside each other, to no end effect but multiplying time (it is providing a nice, smooth surface on the sides, but at a high cost in time). One way to combat that is to reduce the 'steps' param - taking it down to a value like 10 will dramatically decrease the time it takes to render - the down-side is, it'll have a bumpier surface, as we're still getting the edges made up of spheres of radius end_rad. That can be fixed by using a reasonable number of thinner, non-minkowski, plates between the top and bottom plates, and stacking them vs overlapping them, so we get the nice curved edges on top and bottom, but construct things without the inefficient overlaps. But, for the sake of sanity, try reducing 'steps' to 10; it should render in a matter of a few minutes on a decent machine, with that change alone. (could be 4-5 minutes, depending on your machine.) I'll play further with improving that process. Item #2 is where the $fn system parameter comes into play. (There are two lower-level params, $fa and $fs, that are calculated from $fn, and that can sometimes provide better performance if set directly, vs via $fn, so those bear playing with a bit, too.) So, to start with, my $fn choices were made without responsible consideration of actual render efficiency. (They'll give *great* results, but you'll need to wait *great* amounts of time for them.) Setting $fn=12 before the minkowski() call should speed things up considerably, and fiddling with $fa and $fs, vs clobbering them by setting $fn, might yield even better results. I'll play around with those a bit, and see if there's a sweet spot, but to start with, I'd add "$fn=12;" on the line before the minkowski() call in the component_plate() module. I'd also either remove or reduce the $fn=45 param passed to the 'sphere()' command at the end - stipulating 45 faces to make a tiny sphere was a pretty grossly inefficient choice on my part. So, below are the changes I've discussed above (reducing 'steps', reducing '$fn', and its rendering for me in about 90 seconds. Its got a bumpy side surface, but we can work that out. (You can also increase 'steps', just realize that it'll come at the cost of time.) Anyway, this is a solvable problem! :-) Nice job on the approach to the lightening holes, BTW - you're totally getting the 'OpenSCAD Way' of things!! len = 245; //total length wid = 120; //base width (twist will result in wider overall dimensions) edge_rad = 4; //edge radius of top and bottom surfaces ht = 23; //minimum height (cant and/or lift will result in taller overall height) - NOTE: ht must be >= 2*edge_rad twist = 27; //degrees of twist cant = -3; //degrees of cant - this simple demo only supports positive (leftward) cant lift = 0; //degrees of lift - this simple demo only supports positive (heel) lift screw_size = 6.25; //screw hole size lightening_hole_spacing = 10; // spacing between lightening holes lightening_hole_size = 35; //self explanatory steps = 10; //smoothness factor - more steps = smoother sides //this adjusts the total height, to take into account height added due to the edge radius - shouldn't be changed by user adj_ht = ht - 2*edge_rad; sh_rad = screw_size / 2; // screw hole radius lh_size = ((wid-40)/4)-7; // lightening hole size lhz = lightening_hole_size / 2; //call the plate module to initiate the render difference() { plate(); //center lightening hole cylinder(h=100,r=lhz, center=true); //screw holes translate([20,20,0]) cylinder(h=100,r=sh_rad,center=true); translate([20,-20,0]) cylinder(h=100,r=sh_rad,center=true); translate([-20,20,0]) cylinder(h=100,r=sh_rad,center=true); translate([-20,-20,0]) cylinder(h=100,r=sh_rad,center=true); //lightening holes for (i=[0,180]) rotate(i) lightening_holes(); } module lightening_holes() { translate([0,(wid/2+18)/2,0]) cylinder(h=100,r=lh_size,center=true); rotate([0,0,twist/2]) { translate([len/2 - lhz - lightening_hole_spacing*2,0,0]) cylinder(h=100,r=lhz,center=true); translate([len/2 - lhz*2 - lightening_hole_spacing*4,lhz + lightening_hole_spacing/2,0]) cylinder(h=100,r=lhz,center=true); translate([len/2 - lhz*2 - lightening_hole_spacing*4,-lhz - lightening_hole_spacing/2,0]) cylinder(h=100,r=lhz,center=true); } } //because OpenSCAD performs all rotations around the X, Y and Z axes, it is necessary to move the geometry to // proper relative position wrt X, Y and Z. Cant and Lift will be rotated wrt X and Y axes, respectively, so // for Cant and Lift rotations, the geometry should be aligned with X and Y axes //for Tiwst rotation, because this needs to be around the center of the plate, the geometry must be centered // on the Z axis, which requires moving the piece so it is centered at Z, rotating around Z, then moving it // back to where it needs to be (it needs to be in a different position for Z rotation than for X and Y rotation...) module plate() { lift_rot_shift = lift>0?-1:1; cant_rot_shift = cant>0?-1:1; //translate([len/2, wid/2 + (len - wid)/2 * tan(abs(twist)), edge_rad]) for (s = [0:1:steps-1]) { translate([0, 0, adj_ht/steps * s]) rotate([0, 0, twist/steps * s]) translate([lift_rot_shift*len/2, cant_rot_shift*wid/2, 0]) rotate([cant/steps * s, -lift/steps * s, 0]) translate([-lift_rot_shift*len/2, -cant_rot_shift*wid/2, 0]) component_plate(); } } //generate a plate of the desired length and width, with a thicness of 2*edge_rad (this how minkowski() works) // minnkowski operation here is cheap/quick, as its applied to a very thin piece of geometry //$fn value should be high on the end radii, for smooth side surfaces on the end module component_plate() { $fn=12; minkowski() { hull() { //note the adjustment for edge_rad contribution to X and Y that will be added back by minkowski() translate([-len/2 + wid/2, 0, 0]) cylinder(r=wid/2 - edge_rad, h=.001, $fn=120); translate([len/2 - wid/2, 0, 0]) cylinder(r=wid/2 - edge_rad, h=.001, $fn=120); } sphere(r=edge_rad); } }
  14. see if this version of the plate() module fixes the cant and lift direction limitation - now it should handle negative lift and/or cant values, and do the right thing, I think. (Note... very minimal testing was done...) module plate() { lift_rot_shift = lift>0?-1:1; cant_rot_shift = cant>0?-1:1; translate([len/2, wid/2 + (len - wid)/2 * tan(abs(twist)), edge_rad]) for (s = [0:1:steps-1]) { translate([0, 0, adj_ht/steps * s]) rotate([0, 0, twist/steps * s]) translate([lift_rot_shift*len/2, cant_rot_shift*wid/2, 0]) rotate([cant/steps * s, -lift/steps * s, 0]) translate([-lift_rot_shift*len/2, -cant_rot_shift*wid/2, 0]) component_plate(); } }
  15. BTW, you can bump up the $fn on the sphere in the minkowski operation a fair bit - something like $fn=60 will add a few seconds to the render, but end with much smoother edges. ($fn=45 might even be a good compromise between smoothness and speed) ex - just adding "$fn=60" to the sphere command module component_plate() { minkowski() { hull() { //note the adjustment for edge_rad contribution to X and Y that will be added back by minkowski() translate([-len/2 + wid/2, 0, 0]) cylinder(r=wid/2 - edge_rad, h=.001, $fn=120); translate([len/2 - wid/2, 0, 0]) cylinder(r=wid/2 - edge_rad, h=.001, $fn=120); } sphere(r=edge_rad, $fn=60); //<<== $fn=60 added here } }
×