geared part

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

geared part

jon_bondy
I have been asked to print a geared part off of a Sears Craftsman table
saw (Sears is unable to provide a replacement part for a three year old
saw!).  The part is a plate with holes in it (simple), a curved slot
(relatively simple) and a curved set of gear teeth (not that simple, for
me).

I suppose I could start out by pretending that I have a full gear of the
required diameter (presuming that I am able to infer that) and teeth
(presuming that I am capable of measuring that) and then mask it with
the plate.

Any recommendations in terms of gear libraries (I recall there are quite
a few) and process (how to measure teeth, radius, etc).


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

capveg
The MCAD library that is part of OpenSCAD is not a bad place to start
(https://github.com/openscad/MCAD).  I've found a few bugs (and
submitted a few patches :-) in it (specific issue about pitch diameter
being calculated incorrectly) but largely works for me (TM).

Hope that helps,

- Rob
.

On Thu, May 30, 2019 at 9:42 PM jon <[hidden email]> wrote:

>
> I have been asked to print a geared part off of a Sears Craftsman table
> saw (Sears is unable to provide a replacement part for a three year old
> saw!).  The part is a plate with holes in it (simple), a curved slot
> (relatively simple) and a curved set of gear teeth (not that simple, for
> me).
>
> I suppose I could start out by pretending that I have a full gear of the
> required diameter (presuming that I am able to infer that) and teeth
> (presuming that I am capable of measuring that) and then mask it with
> the plate.
>
> Any recommendations in terms of gear libraries (I recall there are quite
> a few) and process (how to measure teeth, radius, etc).
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

jon_bondy
Rob:

Thanks!

When I specify gear(800 teeth, 5 pitch, and 3.5 clearance), I get a gear
that is only about 20 mm in diameter.  800x5 implies a circumference of
about 4 meters.  I must be misunderstanding the parameters

Jon

On 5/31/2019 1:36 AM, Rob Sherwood wrote:
> The MCAD library that is part of OpenSCAD is not a bad place to start
> (https://github.com/openscad/MCAD).  I've found a few bugs (and
> submitted a few patches :-) in it (specific issue about pitch diameter
> being calculated incorrectly) but largely works for me (TM).
>
> Hope that helps,
>
> - Rob
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

adrianv
My impression of MCAD is that it's kind of embarrassing to have as the
"official" library.  I haven't specifically examined the gears code---maybe
it's not so bad---but if you're having trouble you might try BOSL instead:

https://github.com/revarbat/BOSL/wiki/involute_gears.scad

Or google and see what you come up with.  This library looks interesting,
for example:

https://www.thingiverse.com/thing:1604369



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

NateTG
> ... My impression of MCAD is that it's kind of embarrassing to have as the
"official" library.

It seems like doing a "proper" gear library would require going through
something like Machine's Handbook for guidance on clearance calculations and
such.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

capveg
Fwiw, with the proper bug fixes in place, I've been able to properly mesh the involute gears printed with the MCAD library with gears printed from other tools (e.g., Fusion 360's gear library).  See https://github.com/openscad/MCAD/pull/29 for an important stack of bug fixes which would be nice to be merged :-/

But at least for my own work, I hack (sigh) around this issues by adding a wrapper function that undoes the bugs (and a fix to properly calculate helix angle to the gears).  See the note below in my example code, but you should be able to get correct gear sizes by multiplying the pitch by 180/PI to fix the long standing bug.

As for using the calculations from a solid reference, that's effectively what the gear library does... except there's a bug.

Also see my question about a maintainer for MCAD libraries :-)   https://github.com/openscad/MCAD/issues/32  Maybe with the new release (whoo!) of openscad, it's time to clean up the MCAD libraries too?  I can try to help a bit..

Hope this helps,

- Rob
.

use <MCAD/involute_gears.scad>  // for involute_gear()

module robs_gear(number_of_teeth,         // must specify
                modulus,                // must specify, SI units for pitch
                // my defaults
                backlash=default_backlash,
                gear_thickness=5,
                bore_diameter=0,
                left_gear = false) {
    twist_dir = left_gear? 1 : -1;
    // 'twist' adjusts the angle with the height, while helix_angle
    // is a constant angle.  Use this formula to translate.
    opposite =  tan(helix_angle) * gear_thickness;  // opposite of triangle
    diameter = number_of_teeth * modulus * pi;      // pitch diam of gear
    // ratio of opposite / diameter = twist / 360
    // solve for the twist gets you...
    twist_refactor = twist_dir * 360 * opposite/ diameter;
                       ;
    // call the library from MCAD/involute_gears
    gear(number_of_teeth=number_of_teeth,
         // this library incorrectly divides by 180 instead of pi in a
         // critical calculation.  If broken_gear_lib is 1, then reverse this!
         circular_pitch=(modulus * pi * broken_gear_lib * 180/pi ),

         twist=twist_refactor,
         backlash=backlash,
         gear_thickness=gear_thickness,
         rim_width=100,  // TODO: figure out how to make this go away always
         rim_thickness=gear_thickness,
         hub_diameter=0,
         hub_thickness=0,
         bore_diameter=bore_diameter
        );
}


On Sat, Jun 1, 2019 at 3:44 AM NateTG <[hidden email]> wrote:
> ... My impression of MCAD is that it's kind of embarrassing to have as the
"official" library.

It seems like doing a "proper" gear library would require going through
something like Machine's Handbook for guidance on clearance calculations and
such.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

adrianv
capveg wrote
> Also see my question about a maintainer for MCAD libraries :-)
> https://github.com/openscad/MCAD/issues/32  Maybe with the new release
> (whoo!) of openscad, it's time to clean up the MCAD libraries too?  I can
> try to help a bit..

The MCAD libraries need more than a "clean up" to be a valuable tool.  When
I came to OpenSCAD I asked the question here, "where are the libraries" and
the prevailing answer from the vocal responders was "We don't need
libraries.  Just write stuff yourself."  Maybe this explains the dismal
state of libraries for OpenSCAD.  What OpenSCAD needs (for the rest of us
who want to use a library) is a well written, well organized library that
extends its capabilities.  MCAD is a disorganized amalgamation of a bunch of
random stuff, not a coherent and complete extension of base OpenSCAD.  It
does not seem like a good starting point for coming up with a good library,
and certainly is far from being a good library as it stands.  

I surveyed all the libraries I could find and concluded that BOSL was the
library with the most promise.  It tries to do what a basic foundational
library should do, and then adds a bunch of other interesting stuff beyond
that.  It is actively maintained, well documented on its wiki with lots of
examples, and work is underway to make an even better version in BOSL2.  I
suggest that it would be better to take a look at BOSL and help make it
better rather than trying to somehow fix MCAD---I think the latter would be
wasted effort given that a much better option already exists.  (If you find
a bug it actually gets fixed, and if you want to make suggestions for major
additions or changes to BOSL2, the maintainer is listening.)  

https://github.com/revarbat/BOSL/wiki

Note that BOSL2 was started to break free from backwards compatibility with
BOSL and it is unstable now, as the interface is being modified to make
things more uniform and to make some new features better integrated.  So
it's the place to look if you're interested in development, and where things
are headed, but not if you want a stable library that will still run your
model next month without changes.  This means that now is the time to make
proposals if you think there's something that should be really different.  

https://github.com/revarbat/BOSL2/wiki




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

capveg
I'm all for trying to find the Right Thing and am happy to apply my own personal elbow grease to what ever the consensus happens to be.

That said, if folks follow the thread in the  https://github.com/openscad/MCAD/issues/32 issue task, a few meta issues came up:

1) If we do libraries, do we need to also do package management?
2) What is the right way to create an automated test to verify that the library is doing what it claims (e.g., is the generated gear the correct size)?
3) [didn't come up, but should have] How do we do name spacing, e.g., so that my library doesn't use names that conflict with your library?

My take is a lot of these problems seem like re-inventing the wheel to me and may be harder to solve in openscad than is worth investigating, but I'm happy to be proven wrong.

- Rob
.

On Sat, Jun 1, 2019 at 3:54 PM adrianv <[hidden email]> wrote:
capveg wrote
> Also see my question about a maintainer for MCAD libraries :-)
> https://github.com/openscad/MCAD/issues/32  Maybe with the new release
> (whoo!) of openscad, it's time to clean up the MCAD libraries too?  I can
> try to help a bit..

The MCAD libraries need more than a "clean up" to be a valuable tool.  When
I came to OpenSCAD I asked the question here, "where are the libraries" and
the prevailing answer from the vocal responders was "We don't need
libraries.  Just write stuff yourself."  Maybe this explains the dismal
state of libraries for OpenSCAD.  What OpenSCAD needs (for the rest of us
who want to use a library) is a well written, well organized library that
extends its capabilities.  MCAD is a disorganized amalgamation of a bunch of
random stuff, not a coherent and complete extension of base OpenSCAD.  It
does not seem like a good starting point for coming up with a good library,
and certainly is far from being a good library as it stands. 

I surveyed all the libraries I could find and concluded that BOSL was the
library with the most promise.  It tries to do what a basic foundational
library should do, and then adds a bunch of other interesting stuff beyond
that.  It is actively maintained, well documented on its wiki with lots of
examples, and work is underway to make an even better version in BOSL2.  I
suggest that it would be better to take a look at BOSL and help make it
better rather than trying to somehow fix MCAD---I think the latter would be
wasted effort given that a much better option already exists.  (If you find
a bug it actually gets fixed, and if you want to make suggestions for major
additions or changes to BOSL2, the maintainer is listening.) 

https://github.com/revarbat/BOSL/wiki

Note that BOSL2 was started to break free from backwards compatibility with
BOSL and it is unstable now, as the interface is being modified to make
things more uniform and to make some new features better integrated.  So
it's the place to look if you're interested in development, and where things
are headed, but not if you want a stable library that will still run your
model next month without changes.  This means that now is the time to make
proposals if you think there's something that should be really different. 

https://github.com/revarbat/BOSL2/wiki




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: geared part

tp3
In reply to this post by adrianv
On 01.06.19 14:53, adrianv wrote:

> capveg wrote
>> Also see my question about a maintainer for MCAD libraries :-)
>> https://github.com/openscad/MCAD/issues/32  Maybe with the new release
>> (whoo!) of openscad, it's time to clean up the MCAD libraries too?  I can
>> try to help a bit..
>
> The MCAD libraries need more than a "clean up" to be a valuable tool.  When
> I came to OpenSCAD I asked the question here, "where are the libraries" and
> the prevailing answer from the vocal responders was "We don't need
> libraries.  Just write stuff yourself."  Maybe this explains the dismal
> state of libraries for OpenSCAD.  What OpenSCAD needs (for the rest of us
> who want to use a library) is a well written, well organized library that
> extends its capabilities.  MCAD is a disorganized amalgamation of a bunch of
> random stuff, not a coherent and complete extension of base OpenSCAD.  It
> does not seem like a good starting point for coming up with a good library,
> and certainly is far from being a good library as it stands.

How about we stop throwing around all those negative claims of
things supposedly being useless or wasted effort? That includes
your dismissal of MCAD in a voice that is probably offending a
bit to those who wrote some of the scripts maybe 10 years ago
when OpenSCAD was still in its infancy and are still around here
reading those statement. Do you think that gets anyone motivated
improving things?

MCAD was abandoned years ago and for some time is now slowly
maintained by hyperair, but one person can do only so much.
Getting this kind of "support" I see here lately is not likely
to provide much motivation to improve things.
I certainly appreciate whatever time is spend on improving
things even if it goes slowly. And there _are_ fixes getting in
in both MCAD-master and also the development version which tries
to improve in a more general way.
  https://github.com/openscad/MCAD/commits/master
  https://github.com/openscad/MCAD/commits/dev

So what I'm asking is simply to not bash things one does not prefer
to use. A question of "can you suggest a library" does *NOT* need
to start with "MCAD is crap, ... use ...". Praising the nice lib
will give anyone reading that (maybe much later on the forum) the
same information without the negative comments littered around.

That said there are awesome newer libraries around that are nicely
documented and maintained. That includes BOSL and also dotSCAD and
maybe (hopefully) BOLTS which seems to get some updates again.

To bring that rant to end with a hopefully positive note, let me
also ask for other libs that fit the "very useful and well documented"
label and I will put together a list to put on the OpenSCAD website
(Note: Initially I'm only interested in libraries with a FLOSS
license). I'll create a new topic for that, lets see if we can
collect some that are not yet widely known.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
tp3
Reply | Threaded
Open this post in threaded view
|

Re: geared part

tp3
In reply to this post by capveg
On 01.06.19 15:09, Rob Sherwood wrote:
> I'm all for trying to find the Right Thing and am happy to apply
> my own personal elbow grease to what ever the consensus happens to
> be.

Why concensus? I don't believe that is need and I suspect it will
not be possible to get everyone to agree anyway.
I think it's great to have multiple options with maybe slightly
or very much different focus to select from. This also ensures a
more stable eco-system in general.

I'd say have a look at the different options and go with the one
you like best. That usually is also a good base for more long term
motivation.

> 1) If we do libraries, do we need to also do package management?

Yes, I think we do.

> 2) What is the right way to create an automated test to verify
> that the library is doing what it claims (e.g., is the generated
> gear the correct size)?

MCAD uses pytest to do some simple verification, OpenSCAD has the
graphics output based test framework. Both together could be a
very powerful tool. Right now it's not written to be used in some
different project, but that is certainly a possibility.

> 3) [didn't come up, but should have] How do we do name spacing,
> e.g., so that my library doesn't use names that conflict with
> your library?

I have not seen any common way to do that yet. Some libs use a
simple prefix. The solution mid/long term is certainly to support
namespace in the language but so far there's not much detailed
discussion how to do that in compatible way.

> My take is a lot of these problems seem like re-inventing the
> wheel to me and may be harder to solve in openscad than is worth
> investigating, but I'm happy to be proven wrong.

I'd agree with that in general. However there might be always
some incentive to re-invent the wheel as can be seen in other
similar areas too (like ECAD symbol/footprint libraries). This
does depend on the setting the things are used in. For an EE
professional it's sensible to create their own symbol/footprint
libraries along the way as they then have only themselves to
blame if things go wrong. For the casual KiCAD user like me the
nice included libs are very welcome.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: geared part

adrianv
In reply to this post by capveg
I think that ultimately trying to really solve the three points you raise is
hard and will block meaningful progress.  We just need to ignore those
issues and try to press forward, or nothing is going to happen.  

It seemed clear to me that hoping for consensus was too much.  As I noted,
there's a vocal group that thinks we don't need libraries and seems kind of
opposed to the idea.  They argue that it's easier to just write stuff from
scratch rather than learning to use a library.  The sort of library that
might interest that group of people (if you could find one) is going to be
quite different from the sort of library that I think we need.  When I
raised this issue a few months ago it was pretty clear that finding any kind
consensus was going to be impossible.  I decided that it made more sense to
try to build something good and hope that people would use it.  

It seems that right now there is no good solution to the name space problem.  
And it's only made worse by the fact that we can't use "use" due to its
performance problems.  However, there are also not tons of libraries, so in
some sense, the chance of conflict is low.  One way to avoid conflict is to
put everything into one big library and design it so there's no conflict,
which is the approach BOSL is taking, I would say.  

Package management is a nice idea.   Especially if we had some sort of
automatic package fetching mechanism that would just install necessary
packages.  But that would have to be done outside of OpenSCAD and raises
more issues.  I think package management is also not really a major issue
until there are lots of libraries.  At least two package management
approaches have been suggested over the years.  But it seems like this
presents an extra hurdle and extra complication for just building support
for a core library.  

In BOSL there is validation code.  I haven't looked at it and don't know how
it works.  The examples in the manual are all automatically generated from
comments in the code, which serves as another check on code validity.  


capveg wrote

> I'm all for trying to find the Right Thing and am happy to apply my own
> personal elbow grease to what ever the consensus happens to be.
>
> That said, if folks follow the thread in the
> https://github.com/openscad/MCAD/issues/32 issue task, a few meta issues
> came up:
>
> 1) If we do libraries, do we need to also do package management?
> 2) What is the right way to create an automated test to verify that the
> library is doing what it claims (e.g., is the generated gear the correct
> size)?
> 3) [didn't come up, but should have] How do we do name spacing, e.g., so
> that my library doesn't use names that conflict with your library?
>
> My take is a lot of these problems seem like re-inventing the wheel to me
> and may be harder to solve in openscad than is worth investigating, but
> I'm
> happy to be proven wrong.
>
> - Rob
> .
>
> On Sat, Jun 1, 2019 at 3:54 PM adrianv &lt;

> avm4@

> &gt; wrote:
>
>> capveg wrote
>> > Also see my question about a maintainer for MCAD libraries :-)
>> > https://github.com/openscad/MCAD/issues/32  Maybe with the new release
>> > (whoo!) of openscad, it's time to clean up the MCAD libraries too?  I
>> can
>> > try to help a bit..
>>
>> The MCAD libraries need more than a "clean up" to be a valuable tool.
>> When
>> I came to OpenSCAD I asked the question here, "where are the libraries"
>> and
>> the prevailing answer from the vocal responders was "We don't need
>> libraries.  Just write stuff yourself."  Maybe this explains the dismal
>> state of libraries for OpenSCAD.  What OpenSCAD needs (for the rest of us
>> who want to use a library) is a well written, well organized library that
>> extends its capabilities.  MCAD is a disorganized amalgamation of a bunch
>> of
>> random stuff, not a coherent and complete extension of base OpenSCAD.  It
>> does not seem like a good starting point for coming up with a good
>> library,
>> and certainly is far from being a good library as it stands.
>>
>> I surveyed all the libraries I could find and concluded that BOSL was the
>> library with the most promise.  It tries to do what a basic foundational
>> library should do, and then adds a bunch of other interesting stuff
>> beyond
>> that.  It is actively maintained, well documented on its wiki with lots
>> of
>> examples, and work is underway to make an even better version in BOSL2.
>> I
>> suggest that it would be better to take a look at BOSL and help make it
>> better rather than trying to somehow fix MCAD---I think the latter would
>> be
>> wasted effort given that a much better option already exists.  (If you
>> find
>> a bug it actually gets fixed, and if you want to make suggestions for
>> major
>> additions or changes to BOSL2, the maintainer is listening.)
>>
>> https://github.com/revarbat/BOSL/wiki
>>
>> Note that BOSL2 was started to break free from backwards compatibility
>> with
>> BOSL and it is unstable now, as the interface is being modified to make
>> things more uniform and to make some new features better integrated.  So
>> it's the place to look if you're interested in development, and where
>> things
>> are headed, but not if you want a stable library that will still run your
>> model next month without changes.  This means that now is the time to
>> make
>> proposals if you think there's something that should be really different.
>>
>> https://github.com/revarbat/BOSL2/wiki
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

adrianv
In reply to this post by tp3

> How about we stop throwing around all those negative claims of
> things supposedly being useless or wasted effort? That includes
> your dismissal of MCAD in a voice that is probably offending a
> bit to those who wrote some of the scripts maybe 10 years ago
> when OpenSCAD was still in its infancy and are still around here
> reading those statement. Do you think that gets anyone motivated
> improving things?

You're right.  I don't mean to insult the people who wrote things ten years
ago that are in MCAD, or to suggest that this effort was wasted.   Part of
the challenge of library design is having a vision for how the base language
should be extended, and such ideas take time to develop, and experience.  We
benefit now from the last ten years of development.  





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

capveg
In reply to this post by tp3


On Sat, Jun 1, 2019 at 4:28 PM Torsten Paul <[hidden email]> wrote:

How about we stop throwing around all those negative claims of
things supposedly being useless or wasted effort? That includes
your dismissal of MCAD in a voice that is probably offending a
bit to those who wrote some of the scripts maybe 10 years ago
when OpenSCAD was still in its infancy and are still around here
reading those statement. Do you think that gets anyone motivated
improving things?

There seems to be some confusion about which person in the thread you're replying to.  I'm the one that suggested MCAD in the first place (not dismissed it) and one of the people who has been trying to provide patches to update it.  As I posted originally, it works for me if you work around the well known bugs.  I'll say again: I'm happy to help make it better but there is not a consensus as to how to do that.

- Rob
.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

cacb
In reply to this post by adrianv
On 2019-06-01 15:46, adrianv wrote:
> It seemed clear to me that hoping for consensus was too much.  As I
> noted,
> there's a vocal group that thinks we don't need libraries and seems
> kind of
> opposed to the idea.  They argue that it's easier to just write stuff
> from
> scratch rather than learning to use a library.

I saw that discussion some time ago. Very odd.

> The sort of library that
> might interest that group of people (if you could find one) is going to
> be
> quite different from the sort of library that I think we need.  When I
> raised this issue a few months ago it was pretty clear that finding any
> kind
> consensus was going to be impossible.  I decided that it made more
> sense to
> try to build something good and hope that people would use it.

Exactly.

To try to come up with "consensus" before something has been made is
usually a waste of time and will often drain away resources from useful
work. When good libraries appear they are useful regardless of
"consensus".

Libraries are meant to be a way of facilitating re-use of software
components. However, it is often forgotten that an ability to re-use
something is not the only requirement to a library. As Bjarne Stroustrup
once said: "For something to be re-usable, it must first be usable". It
may sound like a joke, but there are many "re-unusable" libraries in the
software world. It is harder to write a good re-usable library to be
used by many than to write a one-off piece of code.

The BOSL/BOSL2 libraries seem to be well documented, and that is one of
the most important aspects of making useful libraries.

> Package management is a nice idea.   Especially if we had some sort of
> automatic package fetching mechanism that would just install necessary
> packages.  But that would have to be done outside of OpenSCAD and
> raises
> more issues.

If a library is found in a github repository, it can be cloned into a
location where the application can find it. That is for many practical
purposes a library package management system good enough.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: geared part

tp3
In reply to this post by capveg
> There seems to be some confusion about which person in
> the thread you're replying to.

I'm not sure why, both the forum post reference and the
quotes in the text show that this was a reply to the post
from adrianv.

I saw your references to the pull requests and it's great
to see those contributions. I did answer to your post
separately and I think I pretty much share your point of
view regarding libraries.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: geared part

lostapathy
In reply to this post by cacb


On 6/1/19 9:33 AM, [hidden email] wrote:
On 2019-06-01 15:46, adrianv wrote:
It seemed clear to me that hoping for consensus was too much.  As I noted,
there's a vocal group that thinks we don't need libraries and seems kind of
opposed to the idea.  They argue that it's easier to just write stuff from
scratch rather than learning to use a library.

I saw that discussion some time ago. Very odd.

It's not just that they don't like the idea, it's that they're actively hostile to the idea of libraries to the point I've talked to a handful of people who wanted to get involved but stay away because of it.

It's really a shame.  A good library ecosystem detracts nothing from users who don't want to use it, they can just continue to not use it.  At the same time, there's very clearly a lot to be gained by some users (and users who don't yet use OpenSCAD!) by having a good library ecosystem.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

lostapathy
In reply to this post by tp3
3) [didn't come up, but should have] How do we do name spacing,
e.g., so that my library doesn't use names that conflict with
your library?
I have not seen any common way to do that yet. Some libs use a
simple prefix. The solution mid/long term is certainly to support
namespace in the language but so far there's not much detailed
discussion how to do that in compatible way.


My take in experimenting with this is that separate namespaces is less of a show stopper than people think, assuming a couple things.

1)  You only have libraries you are using for the current project on your OPENSCADPATH (like scad_bundler does)
2)  The libraries are well-structured so that you can "use" files that only import the parts of the "public API" you need into your code and don't require you to "include" a broad range of "internal functions" to make them work.

I very much think we have all the pieces in place to build good, usable libraries, but they are underutilized and under-contributed-to because the prevailing method of "share it on thingiverse" is terrible for distribution, updates, and collaboration.  Because of that, we haven't really figured out, as a community, "best practices" for making great libraries that are heavily useful and reusable.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

nophead
Another aspect to this is frameworks. My own library is set up for automation with Python scripts. It makes BOMS, stl files, dxf files, assembly diagrams and build documentation like the Mendel90 build manual, which was largely manual but is now automated  for every new project I make using Markdown fragments in the OpenSCAD comments.. For that to work it has lots of conventions and a very particular coding style. For example any module that makes and stl must be called something_stl() and call a module stl("something"). Then it appears on the BOM, gets generated automatically and rendered for the build instructions. 

For example this code:
//
//! * Attach the four feet using 10mm M3 dome screws, washers above and below and nyloc nuts
//
module feet_assembly()
assembly("feet") {
    base_assembly();

    foot_positions()
        foot_assembly(base_thickness, foot);
}


Generates this:

Feet Assembly

Vitamins

QtyDescription
8Washer M3 x 7mm x 0.5mm
4Screw M3 dome x 10mm
4Nut M3 nyloc

3D Printed parts

4 x foot.stl
foot.png

Sub-assemblies

1 x base_assembly
base_assembled_tn.png

Assembly instructions

feet_assembly.png

  • Attach the four feet using 10mm M3 dome screws, washers above and below and nyloc nuts

feet_assembled.png

For that reason I could never use anybody else's library. For example if I wanted an involute gear I wouldn't use MCAD because it wouldn't fit in my framework. I would look up the maths and write my own, so that any gears I designed got added to the BOM, STL file automatically generated and rendered into the build instructions. The only reason I haven't done that is because I haven't designed anything with gears in it. My own library only has things I have used, nothing more, nothing less.

On Sat, 1 Jun 2019 at 18:18, Joe Francis <[hidden email]> wrote:
3) [didn't come up, but should have] How do we do name spacing,
e.g., so that my library doesn't use names that conflict with
your library?
I have not seen any common way to do that yet. Some libs use a
simple prefix. The solution mid/long term is certainly to support
namespace in the language but so far there's not much detailed
discussion how to do that in compatible way.


My take in experimenting with this is that separate namespaces is less of a show stopper than people think, assuming a couple things.

1)  You only have libraries you are using for the current project on your OPENSCADPATH (like scad_bundler does)
2)  The libraries are well-structured so that you can "use" files that only import the parts of the "public API" you need into your code and don't require you to "include" a broad range of "internal functions" to make them work.

I very much think we have all the pieces in place to build good, usable libraries, but they are underutilized and under-contributed-to because the prevailing method of "share it on thingiverse" is terrible for distribution, updates, and collaboration.  Because of that, we haven't really figured out, as a community, "best practices" for making great libraries that are heavily useful and reusable.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

jon_bondy
The part I'm trying to duplicate looks like this:
http://www.jonbondy.com/scan0001.jpg

I ended up scanning it so that I could try to take off the dimensions
more accurately (the original scan is much higher resolution).

Now I want to lay the scan under my part, in OpenSCAD, so that I can
manipulate the design until it conforms to the scan.

Best I can do is surface() the scan file as a PNG.

I wonder how often it would be useful to put an image file down just as
a template

:)

Jon


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: geared part

nophead
I use InkScape to trace the edges and use the OpenSCAD plugin on Thingiverse to output a polygon in OpenSCAD source format.

On Sun, 2 Jun 2019 at 15:18, jon <[hidden email]> wrote:
The part I'm trying to duplicate looks like this:
http://www.jonbondy.com/scan0001.jpg

I ended up scanning it so that I could try to take off the dimensions
more accurately (the original scan is much higher resolution).

Now I want to lay the scan under my part, in OpenSCAD, so that I can
manipulate the design until it conforms to the scan.

Best I can do is surface() the scan file as a PNG.

I wonder how often it would be useful to put an image file down just as
a template

:)

Jon


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12