Hi Brian, yeah most likely that was hitting the timeout as well, it will be disabled in the next v3 beta.

12,000 points is not really that much memory so it's more likely that it was the same timeout problem.

- Michael

Thank you Michael.

Tip of the day for Windows7: After downloading a few hundred woodworking files, "clear the download list," to maintain the speed
with which the download window pops up.

Sorry for asking again but here's another obstacle:

This script

script: 
/*draw cylinder*/
var factory = moi.command.createFactory( 'cylinder' );
factory.setInput( 1, moi.vectorMath.createFrame() );
factory.setInput( 3, 20 );
factory.setInput( 4, moi.vectorMath.createPoint( 0, 0, 40 ) );
factory.commit();

moi.geometryDatabase.selectAll();

/*chamfer edges*/
factory = moi.command.createFactory( 'chamfer' );
factory.setInput( 0, moi.geometryDatabase.getSelectedObjects() );
factory.setInput( 3, 1 );
factory.setInput( 4, 1 );
factory.commit();

chamfers both ends of the cylinder.

How do I persuade the above script to chamfer just one end?
Input 2 of the factory is a corners list according to the Morrill documentation. You showed me how to select vertex points and that this list actually contains boolean switches. Here I have to select surfaces or Breps, correct?

Maybe de-select a face? EDIT: (or edge)
Try interactively to see what is needed.


Just a thought, how about a flow, to reduce thread depth at head end?

Hello,

This looks very interesting. If I am reading correctly UTS and metric threads follow the same ratio rules, so it might be possible to create a script that would allow for nearly all types of UTS and metric sizes. Is your cutting script ratio based or does it use hard coded values? Thanks.

http://en.wikipedia.org/wiki/ISO_metric_screw_thread

Hi Martin,

> How do I persuade the above script to chamfer just one end?

You'll need to have a sub-object of the brep object to be the input into the chamfer command.

The way chamfer works (you can just use the command to check it out) is that if you have a whole object selected it will chamfer all sharp edges that it can find in the object. If you want to limit the chamfer to only one edge you can select either that edge or a face - selecting a face will target all the edges that belong to the face.

You can access a brep's sub-objects by calling the .getEdges() or .getFaces() methods on the brep object, these return object lists.

Right now with your current script snippet there, it looks like you've got the brep as the current selected object. So you'll need to extract the brep from the "object list" of the selected objects, get the edge or face that you want and then put that edge or face into a new object list and then set that as the input into chamfer.

Then with chamfer being given a face or edge sub-object it will then limit the chamfer to that particular area.


So it would look something like this (untested, may have typos):

// Get the cylinder brep object out of the selected object list.
var sel_list = moi.geometryDatabase.getSelectedObjects();
var cyl = sel_list.item(0);

// Get the first edge of the cylinder.
var cyl_edges = cyl.getEdges();
var first_edge = cyl_edges.item(0);

// Build a new object list with that edge in it.
var chamfer_list = moi.geometryDatabase.createObjectList();
chamfer_list.addObject( first_edge );

// Give the factory the object list with the edge in it as its input.
factory.setInput( 0, chamer_list );


- Michael

Hi Brian, I never used the Flow command before so I doubt I will be able to put this into a script at this time. In the current version I do the tapered helix/rail stuff in an extra step which only works when the threadlength is a multiple of the threadpitch.

Hi OSTexo, my script produces the metric thread profile you've linked to. Basically I generate a cutter object and cut the thread similar as it would be done on a lathe. The only variables required are the thread diameter, the thread pitch and the thread length. The rest is done automatically.

Hi Michael, thanks again for the quick and competent help. No typos, your script worked from the start!
I included it already and can now present another preliminary version of my script. For a good experience run it with the default values first. Just hit Start and the output should look like this:



Completely threaded rods are already geometrically correct for all thread lengths.




EDIT: I deleted the attachement and attached the newest version of this script to the first post of this thread.

Thanks for developing and sharing the script, Martin - the results are looking great!

- Michael

Seems beautiful result!

Hello Martin,

Really cool stuff. How did you manage to knock off the two sides of the triangle that are perpendicular to the cylinder before the cutting operation? I never could get that to work without knocking off the edges so there wouldn't be that sort of self intersecting situation and the cutting surface wasn't skimming to closely to the cylinder. Of course that was a manual operation, perhaps the scripted operations behave differently?

Wicked!! I'de like to see this developed to include inches and other variations.

Thanks Martin.

Thanks to all. UNC threads should be no problem as they seem to have the same geometry as Metric threads: http://en.wikipedia.org/wiki/Unified_Thread_Standard. Other threads e.g Acme will require a different cutter shape.

I'm satisfied when the final version of this script can make make metric normal and fine threads plus UNC and UNF.
I imagine
- a dropdown list where the different threads like "M6 x 1" or "1/4 UNC" can be chosen
- a input field for the thread lenght (which has to be slightly corrected by the script to allow full turns)
- a input field for the length of the not threaded part
- if that is possible by scripting the MoI units will be set to mm

I agree OSTexo making a cutting object that actually cuts as wanted is tricky. If the sweep overlaps or touches over a wider area you're out of luck.
I do it like shown below. The height of the cutting object is equal to the thread pitch and the sweeped profiles only touch at one edge.
The final trick to make this work was to move the profiles out by a tiny amount so the the boolean diff operation sees some difference.
I use 0.1 mm at the moment but I just checked that 0.01 mm seems to work too.

>If the sweep overlaps or touches over a wider area you're out of luck.

I don't know if this makes sense but I wonder if its possible to kind of "boolean union" an object (e.g. a self intersecting sweep) by itself i.e. remove any overlaps and make it one solid object.

Hi Martin,

> I don't know if this makes sense but I wonder if its possible to kind of "boolean union" an
> object (e.g. a self intersecting sweep) by itself i.e. remove any overlaps and make it one
> solid object.

I guess it could be possible in some situations, but it would definitely require a lot more work done to get something that would work well.

Many kinds of self intersecting surfaces are also poorly formed in the intersection area with things like lumpy ripples and not an actual totally clean self intersection even.

- Michael

Hi Michael,

it would be handy in a situation like this where profile, rail and sweep are generated cleanly by script and the Boolean Diff still doesn't work because the sweep profile is intersecting or touching over a larger area. I could then use the cutter profile below for example which just doesn't boolean diff when sweeped because its touching over a larger area I guess. If I could "bake" this sweeped cutting object into one firm solid it would work in the Boolean Diff operation.



I updated the script from yesterday. It now corrects the thread length slightly to allow full turns so it produces correct results for any settings.

Hi Martin, from what you're showing there that's not quite a "self intersection" like when a surface is actually crossing back over its own self.

What you're showing there is more of a "edge overlapping" intersection. Those can work ok if you've got pretty precise geometry, like for instance doing a union on the attached 3DM file seems to work ok.

But when you have something that has edges barely grazing each other and it's constructed from some kind of fitting process like sweeps, what can happen is that in actuality the edge is sort of barely wiggling back and forth above and below the surface and that kind of thing becomes quite difficult for the intersector to get a clean intersection from.

- Michael

Hi Michael,

I attached an example. The 2 mm high profile is generated and placed by a script. The helix pitch is 2 mm. So the profiles just touch when sweeped. The sweeped cutting objects sticks completely into the cylinder so there are no edges sort of barely wiggling back and forth above and below the surface. Still when you boolean diff the cylinder with the sweep it gives no result. Why?

Hi Martin, so yeah you do have self-intersection in that case after performing the sweep. Sorry, I was not able to understand what kind of self intersection you were referring to in the previous 2D only image.

I think it's pretty unlikely that something like that is going to be feasible to automatically clean up.

I guess though that the self intersection in your case here ends up trying to form pretty much a cylinder surface on the outside, if you want a result like that you would probably be looking at something like only sweeping the inside surfaces and having just a solid cylinder surface as the outer piece rather than a self-intersecting sweep that ends up filling up the same area as a cylinder.

- Michael

Metric Series Head Dimension Chart:

http://www.spaenaur.com/pdf/sectionR/R11.pdf

Or better yet:
http://www.spaenaur.com/products.asp?PageID=R

 

There are lots of dimensions here, but no pictures:

http://www.numberfactory.com/index.htm

Hello Martin,

Perhaps this graphic will help to see how I produce my manual thread cutting profile. The helix start point is also the point where the edge of the cylinder to be cut should be placed (major diameter). Since the profile is ratio based that profile should work for any pitch size.

As a side note, to determine that arc in the root of the cutting profile I just drew two construction lines perpendicular to the walls of the profile and used the intersection as the center for the arc.

If I'm thinking correctly, that profile in red should be able to be fixed and scaled accordingly. Perhaps the profile should be scaled down from the scaling point indicated on the image by .9375? For example if the pitch is 2mm, if you scale the cutting profile down by .9375 using the indicated scale point as the origin, you end up with a correctly placed and scaled cutting profile. Then, the helix start point (and position of the cylinder edge to the cut, and outward point on the major diameter on the callout) would be at the center vertically of the cutter profile, and would be placed from the top of the cutter profile downward at pitch * .125, correct? Since you have the helix start point determined, which also is the outward point of the major diameter, you can then determine the start point for the axis of your helix depending on what diameter of screw you would like to produce, just by dropping straight down from the helix start point, then inputting the length of the screw (In the case od an M2 the major diameter usually is 16mm). The third position of the callout is the length of the screw thread, which you could enter numerically to determine the end point on the helix axis. The tricky part would be how to determine how many extra turns you need to run the helix so the cutting profile clears the end of the bolt, but I'm guessing that is probably some sort of formula that can determine that. What is also probably tricky is how to lift the cutting object if you want screws that have a longer total length than thread length. You already know the pitch, so that probably could be put into the pitch field of the helix function. That profile also avoids any problems with intersections and should result in a successful Boolean. Does that make sense?