Thanks Michael, yes with the other alert it seems to work reliable.

Hi Martin, so actually it's not that alert at all, I looked into it some more and it looks like your script is running into a "timeout" mechanism in the script interpreter, due to the continuously spinning while loop here:

	while (!moi.ui.commandUI.GetStart()) {		
	}

A loop like that is going to continuously burn CPU time and at some point the script interpreter notices that it's just churning CPU in a loop and bails on the script.

I should be able to disable that timeout mechanism, but in the meantime you should instead use an event loop for that kind of a thing, if you wait for a UI event that will pause the script until an event is actually generated, the method that you're doing now does not do an actual wait, it's called "polling" where it's just actively checking over and over and over again.

To do the event based method, replace that while loop with this:

	var dlg = moi.ui.commandDialog;

	while ( 1 ) {
	
		dlg.waitForEvent();
		
		if ( dlg.event == 'startbutton' )
			break;
	}

You can also remove the GetStart() script at the top of makethread.htm and also remove the onbuttonclick="" handler on the start button, it's enough for the start button to just have an id value, any control inside of the command UI area will generate a UI event with that id when pressed.


Note that there is still a loop, but that's only because it's possible for other events to be generated too like when other controls are clicked, you want to loop until you get the right event but by calling waitForEvent() on a "waitable object" (if you don't have a pointpicker or object picker then the "command dialog" object can work, it's a waitable object that represents the command UI panel) you won't be burning CPU, the script will actually suspend at that point until a UI event is generated, then it wakes up.


Also if you give your start button an id="done" , you can then #include "WaitForDialogDone.js" in your script and then use WaitForDialogDone(); which is a packaged up function that does that exact same kind of loop in it, it just looks for a UI event named "done" instead of "startbutton".


I've never seen this script interruption mechanism kick in before, so that was kind of mysterious but it was good to find out about it since there may be other situations where you're doing a whole lot of number crunching processing where you would need the script to crunch away in a tight loop for some time, so it's definitely something that I need to disable in the script engine.


- Michael

Hi Martin, so it definitely is this script timeout thing - if you just run makethread once and just let it sit there for about 20 seconds, it will get interrupted and then it will immediately interrupt when you launch it after that as well.

I will be eliminating that for the next beta but for now if you switch to the event-waiting method that I wrote above it will solve the problem, because it's only time actually spent directly in the script engine itself that counts for the timeout period, when the script calls into MoI the time that MoI's backend stuff is working on processing things (or waiting for an event) does not count towards the timeout period.

- Michael

And the alert doesn't have anything to do with it - there was actually a problem with that particular other alert method back earlier in v3 but it's actually been fixed for quite a while now.

- Michael

Hi Michael,

I'm glad you figured that out. I already added the method you suggested but I also want to make the thread more accurate. For this I need a fillet radius on one side of the thread cutting object as shown on the right side:


My problem is selecting this point via script and than to use the Fillet factory correctly. I can't even get filleting all corners to work.

var threadDiameter=10;
var threadPitch=1.5	

/*draw thread cutting profile*/
frame = moi.vectorMath.createFrontFrame();
frame.origin = moi.vectorMath.createPoint( threadDiameter/2, 0, -1*threadPitch );
factory = moi.command.createFactory( 'polygonedge' );
factory.setInput( 0, frame );
factory.setInput( 1, moi.vectorMath.createPoint( threadDiameter/2, 0, 0 ) );
factory.setInput( 2, 3 );
factory.commit();
moi.geometryDatabase.selectAll();

/*round off all corners*/
factory = moi.command.createFactory( 'fillet' );
factory.setInput( 0, moi.geometryDatabase.getSelectedObjects() );
factory.setInput( 3, 0.14434 * threadPitch );
factory.setInput( 4, "circular" );
factory.commit();

Hi Martin, to do a curve fillet you need to create a list with a boolean entry for each vertex and add that to the factory on input 2.

Normally this is done in the Fillet command by calling factory.generateVertices(), then letting the user pick the vertices which are temporary point objects and then calling factory.finishedPickingVertices() at the end of the picking stage, but you can instead directly create a list and add the boolean flags to it, there should be one flag for each segment of the input curve.

So something like this should work:

    factory = moi.command.createFactory( 'fillet' );

    var vertflags = moi.createList();
    vertflags.add( true );
    vertflags.add( false );
    vertflags.add( false );
    factory.setInput( 2, vertflags );

    factory.setInput( 0, moi.geometryDatabase.getSelectedObjects() );
    factory.setInput( 3, 1.0 );
    factory.setInput( 4, "circular" );
    factory.commit();

- Michael

Cool, thanks a lot for the help. I would have never got this to work.

Michael, re: script timeout.

When I was calculating "fibonacci" points with a fibonacci script with nested For Loops, after about
12,000 points, MoI would quit working. I was wondering if this may have been due to this "script timeout" ?

Or maybe it was some kind of memory used up thing?

Thank you,
Brian

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.