Full Version: Anyone wish to develop a custom script?

Show messages:  1-5  6-25  26-45  46-65  66-85  …  206-223

Hi Anthony.

Spent some time studying your pdf of PROP_DESIGN_GEO.fortran program.

Speaking as a non-engineer, and amateur javascript programmer, the 200+/- lines of fortran code are relatively comprehensible,
and creating an (amateur) Moi javascript should be relatively easy.

There are 2 data arrays of 27 elements each. 8 integer variables, PI, 15 indexed variables, and 12 variables.
Unit 3 is for 10 input parameters to put on a .htm input screen for the A400 example.
Function #3, with input Do (for) loops.
Function #4 with calculations.
Function #5 with 27 calculations of Airfoil Points and output of x,y,z points. This would use MoI Factories or Factory.
Function #6 with 13 calculations of Rail Points and output of x,y,z points, for MoI Factory/ Factories.

Think I'll give javascript, for MoI script, a try in the next few days.

---

That's good news. Early you asked what I was looking for. Basically something that had all the inputs in a dialog within MoI and once you entered them the 3d blade/propeller geometry would be generated automatically. As you noted there are 10 inputs into the program. Three integers, four floating point numbers, and 3 switchs that would be toggles or check boxes in the MoI input. The others would be input boxes and possible some sliders, like for number of blades. The Fortran code has everything in meters, degrees, or non-dimensional inputs. The outputs are in meters.

Thanks for working on this. I think it will be really cool and useful once its done.

Anthony

---

I thought it might be nice to have a drop-down menu that would allow to select the example files and to also enter your own data. I am working on getting the example files together. I have to sync up all the different versions of the code. Examples were made and then new versions of the code were made, so the examples aren't in order. It's going to take a little bit because I have to re-code and go through a ton of stuff. But just wanted to give a heads up. I will post an updated code which contains the example input files. It's actually already done for the code you need, but I want to sync all the codes first to make sure its not going to change again.

I modelled the optimized computer case fan blades in MoI and they looked wicked. I think when you get this functioning and users can switch through the examples and make their own, the geo is going to be pretty nice eye candy. I did find again though that it is important to immediately switch to mm after importing the points. then do all the modelling in mm. as the very last function switch back to meters. MoI wasn't able to pick up tangent points when I was in meters. Previously it wouldn't do some of the sweep geo right either. Its some kind of tolerancing thing michael said previously. This applies to version 2.0, not sure about 3.0 or 1.0.

---

Here is the update I mentioned. You can now select from a number of example cases, as well as, use your own inputs. Here is a picture of the computer case fan optimized model.

Edit; See the updated code in post below.

---

Here is a preliminary htm file for the entry screen.
It is based upon looking at several other .htm scripts, trial and error, and guessing :-)
It will need some changes to variables, and formatting (?)
(Current text editor is notepad++)

In MoI3beta, the width self adjusts. In MoI2, the width is squashed.

(Edit, must not use the lessthan or greaterthan symbols, or this post formatting gets weird.) :-))


Michael, is there any documentation of how the MoI .htm works, or what the terms mean?

Thank You

Edit, updated to better versions 12/21/11. (Only one person had downloaded.)

Attachments:
PropDesignGeo.htm

Image Attachments:
Design_a_Prop_BetterScreen2.PNG 

---

The following means: "if there are spaces (white-space) between the words of a text line, do not wrap the words to the next lines"

 code:

style="white-space: nowrap"
:-))

---

Hi Brian,

> (Edit, must not use the lessthan or greaterthan symbols, or
> this post formatting gets weird.) :-))

If you put in HTML tags directly into a message, the forum thinks that you're trying to use that HTML code to format your actual message, so the tags will become part of the HTML and get interpreted by the browser instead of actually displayed as plain text.

But you can disable that by putting what you want to display inside of a <code>...</code> block - anything inside of a code block in a forum message will have its text displayed directly rather than having any of it interpreted as HTML formatting.


> Michael, is there any documentation of how the MoI .htm works,
> or what the terms mean?

No, unfortunately it takes quite a bit of work to fully document all of that stuff, I do not currently have anything like that.

For the regular HTML parts though there is a lot of documentation online.

What terms in particular are you asking about?

- Michael

---

Thank you Michael

Tips on spacing text versus entry boxes would be helpful.

What do the following mean, or how are they used?

style="width:100%;"

style="width:3em; [creates space for decimal places]

style="persist:true;" [style lasts until .....]

---

Hi Brian,

> style="width:100%;"

This one is standard HTML - it means to make the element take up the entire width of its container. On some kinds of elements like a table if you don't set width=100% it can kind of shrink down to be smaller than that if it goes down to just hug the size of the text inside of it. For some kinds of things that would not be good - like imagine the "Done" and "Cancel" buttons if they were like that.


> style="width:3em;

This one is also standard HTML - ems are a measurement unit that is relative to the current font, so that's like saying make it the width of 3 characters of the current font size. See here for more info on CSS units: http://w3schools.com/cssref/css_units.asp


> style="persist:true;"

That one is a MoI-specific attribute - that sets whether a control in the command UI will remember its value on the next run of the command or not - some controls default to persisting the value and if I remember right some controls like text input fields default to not persisting it, but the default persist value can be overwritten by assigning that style property to the specific element.

If an control in the command UI is set to persist then its value is recorded when the command ends, and the next time that command starts up it will get initialized with that value.

- Michael

---

also:

> Tips on spacing text versus entry boxes would be helpful.

Do you have a particular spot where the spacing is not what you want?

Usually for input fields it's easiest to put them into a <table> which will line them up and will put in a bit of default spacing as well.

- Michael

---

Thank you Michael.

I should do more w3schools reading.
I had a missing "table" (unbalanced), so display was messed up.
Adding "white-space:nowrap" helped a lot too.
(updated previous attachments)

Display looks pretty good in MoI3beta.
In MoI2 the display runs off the right side, in scroll. I think there is an old
discussion to widen display in MoI2...
:-))

---

The menu picture you posted looks great so far. Thanks for all the hard work.

---

Thank you Anthony.
It's a hobby for me, plus a learning experience.
Do you need 16 decimal digits for RADIUS?
I should spend a little time getting familiar with the terminology & formulas...

There could be an initial menu with which to select "Fan" or "Predator", or "Piaggio", etc., with the
hidden (multiple?) parameter input menu(s) then activated, or maybe pass the parameter list to one menu?

But for now, the menu is enough for testing. Time to continue work on the .js script.
:-)

If you see anything objectionable, please speak up.
I'm resolving to resist the urge to rename variables.
Data types will be integer or javascript decimal...

---

Hi,

Yeah it would be confusing if you renamed variables on the menu. The radius being carried out so far enables the power to be set precisely. Say the user enters 1200 shp in PROP_DESIGN_OPT, the program will iterate to find all the necessarily information. Radius goes out that far to get the power to come into line. But for the casual user I'm sure they are not going to enter numbers out that far. Since you can't even manufacture to that tolerance. Probably people would tolerance from 3 to 6 decimals normally. If it isn't a problem to carry the numbers out that far it would be good from more of a theoretical standpoint. I like to do all my calculations to as high a precision as I can and then as the very last step round down to the desired decimal point. Otherwise you get a lot of roundoff error building up.

I don't see anything wrong as of yet, looks great. I posted a new version which has some example files you can try. If you want to wait or not even include them that is fine. Just an idea. I have all those examples now in each version of PROP_DESIGN. But its not a big deal to manually enter the inputs.

---

Help with fortran conversion to javascript:
http://www.see.ed.ac.uk/~jwp/JavaScript/programming/notes.html

Array subscripts actually start at zero, but the first element can be ignored...(carefully...)

---

Hi bemfarmer,

I was modelling some of the examples and encountered the mm unit system issue. Basically if you don't use mm all sorts of things don't work in MoI v2 with these models. Also I have to change the mesh angle to 1.0 degrees for some models to display right. Given this I updated the code to output in units of mm instead of meters as previously. I tested some of the examples and they seem fine.

Anthony

Edit; the latest version of this code can be found in a later post.

---

Hi Anthony,

How are you importing your AIRFOIL_POINTS.XYZ and RAIL_POINTS.XYZ files into MoI?
The import point file does not work for me. It shows a Type Mismatch line 112 error.

I finished writing the PropDesign MoI script, and it loads without any errors, (after fixing a few dozen), but nothing is
displayed on the screen, (except alert message, which loops 13 times), :-(.

Is the idea to display the fan/propeller directly on the MoI screen, without creating a point file, and without having to load a point file?

Thank You.

---

Hi,

Yes ideally, if the script created the 3d blade geometry that would be awesome. As far as loading the xyz files that the fortran code created select space formatting from the dropdown menu. also, maybe they didn't update the script on the download page. when i first tried it didn't work either. but someone posted an update to the forum thread. i assumed they uploaded it to the actual place where it is, but maybe not.

i'll attach the files i'm using just to make it easier on you.

what i am currently doing is importing the point files, now in mm. then i create the splines for the airfoil and for the rails. then do a two rail sweep. its not that hard. but its redundant and tedious to do over and over again. the airfoil points aren't quite right so you have to use control point when creating the splines. also you have to make the leading edge and trailing edge arcs. the trailing edge arc is really small so you have to zoom in a lot to see it. if everything is created right it should come out as a solid rather than a collection of joined surfaces. sometimes small errors you can't see will develop and you won't get the solid.

---

Thanks Anthony

Michaels updated import point script works, so I'm getting a better idea what is going on.

(Found the forum thread on "Import Point Script Error" with Michaels updated import point script.)
(The import point script(s) on the kyticka.webzdarma site are the original versions.)

Would an increase from 13 TIP points help any?

Regarding the "splines for the airfoil", where/which are the points, or how are the splines for the "backside" of the airfoil determined?

Are the calculated airfoil points (supposed to be) on the actual physical surface of the propeller?
I'm aware of three factory types to choose from, var factory = moi.command.createFactory( 'interpcurve' ), curves go through the points, or
var factory = moi.command.createFactory( 'curve' ), curves use the points as contol points, or
var factory = moi.command.createFactory( 'point' ), creates points from the x,y,z points.
(The point one just makes points, the current import points situation). (The first two make curves, easier to sweep, no splines to manually create,(except for tip/edge arcs?....)

One factory to create the (closed?) curve of the airfoil cross section.
Three factories to create "top", "bottom," and "middle" rail. ("top" points make 1 rail, "bottom" points make 1 rail, middle points make 1 rail.?)

Is there only one cross section airfoil for the entire rail sweep? (in current model?)
(Excuse dumb questions please, trying to understand the geometry, and which points get connected.)

What are the middle rail points for?


What does each triplett of rail points represent? , (front? back?).

---

Was thinking along these "nonaerodymic" lines:

---

Show messages:  1-5  6-25  26-45  46-65  66-85  …  206-223