Full Version: Anyone wish to develop a custom script?

Show messages:  1-5  …  86-105  106-125  126-145  146-165  166-185  186-205  206-223

> they can now be made through points...
That is good I think. I'll switch to through (interpcurve) points.
It might change the tantan point of the conic a little?

Sorry about the .htm. They have not changed. My amateur "version control" really proliferates a lot of similar named files.
Using calendar date helps a little. :-)

With your fortran data point imports, are you now doing a hub, and adding on 8 blades?

What sort of aircraft engine do they power?

Do you contemplate any change to the outer edge?

---

hi brian,

i believe the example you have as your default is for the Airbus A400M military transport. It is a high power high speed turbo-prop. The geo is an example of what you could try using PROP_DESIGN. The real propeller was designed with proprietary codes and does not look like the one I am using. It's a good example to exemplify the usefulness of PROP_DESIGN.

Yes, I model the hub and then I do the array to 8 blades. I think I have those inputs in prop_design_geo with the thought that you could use them. but even if you don't, it doesn't hurt to have a reminder of what they are for a given case. I do the hub to blade fillet and I define the hub with fillets and all. Then I have one complete blade ready for the array as the final step. However, my hub geo is different than anything used before. I have just been curious to see what it would look like. It hasn't been tested or anything. It is closest to what you see with the retention of blades inside jet engines. I haven't been putting it in the screencasts because it takes a lot of steps to do the hub and everything. I enjoy doing it in MoI though because its like a one for one duplication of how you would do the real life machine ops. The way you do all the boolean work is insightful and fun.

My main thought behind the script would be to keep new users from making mistakes. It has a nice benefit of saving lots of time too. :)

By changes to the edges, I'm thinking you are referring to the rails. If so, there will not be any changes to the rails. There shouldn't have been a change to the airfoil but due to the feedback on the forum, we now have a more accurate definition of the airfoil. At least, I believe/hope so. Sorry I caused you more work by changing things up. I'm still trying to rap my head around what we have now. However, I'm confident there will not be anymore changes to the underlying geometry at this point. For one thing, I can't change the airfoil geometry substantially without performance data to go with it. I constantly see propeller efficiency of about 90%, using PROP_DESIGN, so there should be no need for another airfoil. But even if I wanted to change airfoils, I would still need data to go with it. VisualFoil Plus looks like the program to use, however, I don't have the money for it. So I'm sticking with the airfoil that I have data for.

---

looking into the le some more puts me back to where i was previously. if you take the naca definition of a circle at the le, it is only tangent to the ellipse at one point (the leading edge rail start point). it looks like the tangency points i thought i was getting were a small error with the moi snap points. moreover, i am getting false intersection snap points at times. doing another comparison and ignoring the false snap points, there really is no intersection of the two. the naca le circle really has nothing to do with the ellipse definition either. i thought it might, but am not seeing it upon further review. so this leaves me where i was originally. you can use the conic section as the le and just flat out ignore the naca definition. or you can use the naca le definition and figure out some sort of curve to transition from the circle to the rest of the naca points. at this point, i am content to leave things as they are. i am satisfied with the conic/ellipse le and using all the naca data as through points. when i compared the two options previously the differences were small.

---

As promised, here is an update to PropDesignGeo script for MoI, with through points for airfoil. (interpcurve factory).
The tantan point did change a little bit.

Due to the fact that a change in RADIUS or ROCR causes a change in the airfoil, and require a different tantan point, it
was necessary to reverse calculate the z_tantanPt, for the default airfoil, to a z_AFXTAB point. (Which came out to be, AFXTAB_tantan = -0.57937.)
Wrote a crude excel spreadsheet to reverse the formula. The formula is listed in the script.
AFXTAB_tantan = (250 * (RADIUS/ROCR) - z_tantanPt) / (10 * RADIUS/ROCR).
Now the new tantanPt is correctly calculated, in the event RADIUS or ROCR changes.

Attachments:
PropDesignGeoThru_1_7_2012.7z

Image Attachments:
CompareControlAndThroughAndRadiusChangePts1_8_2012.PNG 

---

hey brian,

i downloaded your latest version and ran two test cases. they match exactly. i'll run the rest of the test cases later, however, i don't expect any issues.

great job as usual.

anthony

---

hi brian,

i was running more of the examples and ran into an issue. the script seems to work fine, i have a few more examples to check but the comparisons are identical. the problem i'm having though is if i try to copy and paste the radius from a text file into the input field in the moi script the script closes and nothing happens. i need it to allow me to paste in the radius and just stay open, letting me press ok on the input. then go on to the rest of the inputs.

if you are done working on the script, it may be a good idea to remove the blade count and hub end point input fields, since they are unused currently. this should cut down on confusion for new users.

finally, are you ok with me posting your script on my website so prop_design users can use it. if so, what kind of credit would you like on the description for the download. for instance, should a reference your moi user id or would you like your actual name as shown in the java script.

thanks,

anthony

---

Hi Anthony,

> the problem i'm having though is if i try to copy and paste
> the radius from a text file into the input field in the moi
> script the script closes and nothing happens.

What process are you using to do the paste part?

In order to paste into the input field, it needs to have focus first - if you try to do it without the input field having focus it thinks that you are trying to invoke the Edit > Paste command for copy/pasting geometry.

But if you click on the input field to activate it, you should then be able to do Ctrl+V to paste your text into it, that works at least in v3 - it looks like in v2 there may be a bug involving that - in v2 click on the field, then push the little X button to close the popup, and then do Ctrl+V.

- Michael

---

thanks michael,

you were right. when you close the popup you can paste into the field. now i can continue checking the script out. :-)

update; it let me paste in the number however the script didn't generate the blade with the right radius. it used the number prior to the paste. so its somehow not accepting the paste, even though it shows it in the input box. perhaps when you hit the x to close the popup anything after that is not being read.

---

Hi Anthony - you have to push Enter after you have done the paste to commit the new value that was just placed there, same as if you had just typed the value in.

- Michael

---

thanks,

that works. i just finished manually entering all the input for the rest of the examples, prior to reading your message. but i went back and tried one with what you mention and it works.

so all the examples i have check out between the script and the output from prop_design. so everything is good as far as i can tell.

---

Hi Anthony and Michael,
Glad everything worked, so far.
Don't know for sure, but hope the script has proper updates, and not too much redundant code. Not sure if I've used
one extra, unnecessary factory or array, and have proper "cleanup," or not...

I'll remove blade count and hub end point.
January has historically been a busy month. Would like to try to script a selection of the 4 airfoil curves, and join them by script... Previous
attempt was not successful. I was thinking maybe history was interfering with the mirrored curve, or maybe it needs to be updated before joining...?
The previous join attempt created duplicates of the three, non-mirrored curves...
May try again..., or just leave it alone...

It might be nice to name the curves, or color them...

---

ok brian,

sounds good. i won't post anything until i here from you. if you are able to auto join and sweep that would be great. i think removing the blade count and hub end point would be ok even if you do the updates you're thinking of. mainly because the person would need to be able to model in moi to continue past the blade creation point. this script should give them enough of a a start and hopefully inspire them to do more on their own. since hub methods vary greatly, the user would need to take over at that point. they have the output from prop_design and/or prop_design_opt that lets them know what the blade count and hub end point are. so it should be good to take them out of the script.

---

Hi Brian,

> Previous attempt was not successful. I was thinking maybe
> history was interfering with the mirrored curve, or maybe it
> needs to be updated before joining...?

I don't think that history should really come into play there - if you give some stuff to Join it won't try to replace the objects that you have given it or anything like that, at least as far as I can remember right now...


> The previous join attempt created duplicates of the three,
> non-mirrored curves...

Hmmm, I guess make sure to double check which curves are actually getting fed into the join factory?

- Michael

---

Spent several hours trying to get join to work. Join factory kept doing endless "calculating" on incorrect, or incomplete, object lists...

Then starting going through Michaels many scripts, looking for non-interactive examples.

Amazingly, the SpurGearProfile script has all of the information and examples to do the join!

The time was not all wasted, as I can now, at least partly, understand the SpurGearProfile script.
Copied/borrowed/modified, some of the code.

The airfoil join now will non-interactively combine a curve, a mirror, a conic, and an arc, into one selection, ready for a users sweep.

The SpurGearProfile also has a "shorthand" function to create differrent types of factories, which would reduce the number of lines of code.
Did not utilize the function, so as to perhaps better demonstrate the various factories used.

Will post update file soon. (Still have to do cleanup, and update for changes...)

It is a little bit confusing whether a curve is a curve, or an object list, or a geometric object, or ...
(The old "trim" posts help a lot.)

---

congrats, you're gonna be an expert by the time you're done

---

Having trouble with cleanup.
Airfoil works great, the first time through, but if any htm changes occur, keeps making a new copy
of the Airfoil piling up on top of the previous one. The profile data type gets changed, I guess...
Seems like the simple factory scripts do cleanup one way, and the factories arrays scripts do cleanup differently.
Gotta stop for today...

---

After a break, have managed to get the join working correctly,
EXCEPT if Cancel is pressed, a copy of the airfoil remains. ???
Do not know why. "Null" is used.
Maybe has something to do with geometryDatabase?


Many portions of the SpurGearProfile script were used, with limited understanding.)
Do not know if a factory or factories array could be used instead?

Update attached.
The control points for the curve are showing, (not for mirror). This can be changed by commenting out 3 lines in the .js.

EDIT, Corrected update 1/15/2012, now Cancel button works properly.

---

Hi Brian,

> After a break, have managed to get the join working correctly,
> EXCEPT if Cancel is pressed, a copy of the airfoil remains. ???

Where is the airfoil geometry coming from? I mean is it the result of calling factory.update() and then factory.commit() ?

Basically the way the factories are set up, you generally want to call .commit() as the last step when you know that the command has not been canceled. If you have only called .update() on a factory and not .commit() then the output of the factory is removed when the current command ends.


> Do not know why. "Null" is used.

"Null" was used how?


> Maybe has something to do with geometryDatabase?

If you added objects to the geometry database directly by calling geometryDatabase.addObject() then those objects will remain in the database even if your command is canceled - if you've directly added stuff like that rather than using a factory to do it for you, then you will also need to remove them from the geometry database as well on canceling (by calling geometryDatabase.removeObject() ) if you don't want them to be there after the command exits.

- Michael

---

Hi Michael,

Well, I am editing this post a lot. I managed to get the Delete key to work properly.
One line prevented "moi.geometryDatabase.removeObjects( airFoilProfile );" from working in the cleanup.

The culprit is: Cancel ( ControlPointsfactories ); occuring before the removeObjects line.
Do not know why... It contains points. The other 3 factories arrays contain curves. They CAN occur before the
removeObjects line.


Note: Replaced attachment 3 posts back, with modification.

---

hi brian,

i was wondering about something. i like the latest version of your script. but i was thinking it may be a lot easier if it started the process by asking which input file you wanted to use and then created the geometry. so it would be a little bit like the import point file script as far as how it starts up asking you to select a file. but after that the geo would just appear and that would be the end of the script.

the reason i think this would be easier is that you wouldn't have to transfer all the inputs from the input file to the moi html window. i have been working on PROP_DESIGN over the last few weeks and released a new version. PROP_DESIGN_GEO has been renamed PROP_DESIGN_XYZ. I took all the geometry creation parts out of the original code. So they now only exist in PROP_DESIGN_XYZ. This allowed me to package PROP_DESIGN_XYZ without causing confusion.

The basic process works by PROP_DESIGN_OPT determining the optimum geometry and creating an input file for PROP_DESIGN_XYZ. This is the same input file that you could read into your script, since it contains all the values you need.

Another option could be that you have inputs in an html window in MoI but the inputs would be for PROP_DESIGN_OPT. The code would run and generate the input file you need to make the geo. The only problem with this is that it takes several minutes for PROP_DESIGN_OPT to run. So I don't think that would be the best option.

The prop_design.zip file on my website contains all the source code and input files you would need to play with.

http://propdesign.weebly.com/primary-download.html

Note that I added a new input at the end of the input files. However, you don't need to use that input for what you are doing. It's there for reference right now.

---

Show messages:  1-5  …  86-105  106-125  126-145  146-165  166-185  186-205  206-223