Full Version: Anyone wish to develop a custom script?

Show messages:  1-20  21-40  41-60  61-80  …  221-223

Hi,

I was wondering if anyone would have any interest in developing a custom script to generate aircraft propeller blades. I wrote some Fortran 77 codes that design aircraft propellers. They output point files to be used with MoI or Rhino. It recently occurred to me that many of the users here may be willing/able to create a custom script to do this work. The challenge would be converting or using Fortran 77, as I know this is not a common language in programming circles. I know nothing of programming. Fortran 77 is something they taught, back in the day, to engineering students. I also encountered it everywhere I worked. So its what I know.

Currently there are several versions of PROP_DESIGN. If someone is interested in working on this, I could make a version that just created the geometry. From an MoI point of view, there would be some sort of onscreen dialog that allowed for a few basic inputs and then the blade(s) would appear onscreen. You could adjust the inputs and the blade(s) would update. So it would save a lot of time basically. Not that it takes much time to do it manually.

The options would be:

a) Review the existing codes as a basis to write a script.
b) Call the existing codes from a script.
c) Have me make a custom Fortran 77 code that you could call from the script.
d) Have me make a custom Fortran 77 code that you can review to make a script. Basically, just making it easier to find the code of interest.

There is a spreadsheet with most of the equations too, but that file doesn't generate any geometry, so not sure if that would be of use. Also, there was an issue with MoI 2.0 needing to do the geometry in mm to capture the small geometry features. The points are in units of meters. So care would be needed to make sure everything worked out ok. Moreover, that all the geometry is generated correctly and in the right units when all is said and done.

I don't do any cad work anymore, as I'm retired. I evaluated MoI because I wanted to be able to recommend something good to PROP_DESIGN users. I only have the no save version of 2.0 on my computer. Ideally it would be nice if the script ran on any version of MoI; 1.0, 2.0, 3.0, 30-day trial, no save versions etc... If that's even possible. At least the current version and current demos. The script would be located with the rest here.

Not sure if you guys think this is a good idea or not. Just thought I'd ask.

Thanks for your time.

Sincerely,

Anthony Falzone

http://propdesign.weebly.com/

---

Anthony,

Is the source code posted there?
With the large amount of information, did not see the source code, after a quick look...


Thank you.

Edit: Are you talking about converting the Fortran 77 code to javascript?
Or importing a point cloud to Moi?

---

Hi,

Thanks for the fast reply. The source code is there. However, after a little thought, I realized it would be best to make a new version. The orignal code is around 3000 lines. The new code, with just the geo is about 300. I just got done testing it and everything looks ok. I made a quick model in MoI and seems fine. I can't save the model as I'm using the no save version.

I am going to attempt to attach a zip file to this message, it contains the new version of PROP_DESIGN, which just makes the rail files for MoI. I am not a programmer so I will leave it to you guys on how to best do this. If you want to just call the Fortran up it runs in a heartbeat. If it is better to make something entirely different, that's ok with me. The end result is all that is important to anyone using this functionality in the future. The reason I am posting the code is that I do not have the equations documented anywhere. So the only way to know what is going on is to read the code, sorry about that.

In any event, when actually making the model in MoI there are a few things I have found. The NACA points are a little off for some reason. I have the points entered verbatim from the NACA document. But when you make the splines in Rhino you have to use them as control points, rather than exact, since there is some error up by the leading edge (the larger radius at the top). Also, I have some points in there to help make the leading and trailing edge arcs. Burrman and Michael have commented on how best to make these arcs for MoI. I don't recall their exact recommendation, but I think they said you needed one arc for the le and one for the te. I had them broken in pieces. I found you have to really inspect the model for smoothness to make sure it is generated correctly. I'm not sure the exact options and methods that are best to get the blades to come out right. What I just tested looked ok, but there may have been some distortion. I'm on a laptop with Intel graphics, so I don't know if it is just the graphics or if the surfaces weren't quite right. This all goes back to figuring out the exact best way to generate the blade. I make an airfoil then I sweep it along the le and te rails. I have an extra rail in there for the 1/4 chord point. This is for reference. Lastly, the hub cutout is not represented in the rails. I do that manually afterwards. The rails go from 0,0,0 to the tip. In the input file there is an input that determines the hub cutout. In the example shown it is 3. There are thirteen points, so this makes the hub cutout 3/13 * radius. For this example that would be approx .603 meters. But a little extra math in the script would be needed from what is shown in the Fortran code, in order to automatically do the hub cutout.

I can answer questions as they arise. Thank you for your interest/help/time.

Anthony

P.S. The code I am attaching is not on my website, I won't be placing it there as it would just be confusing. It is solely for this effort here.

Edit; See the updated code in post below.

---

I should note that the MoI example on my webpage was made awhile ago. So I'm not sure if it agrees with the current A400M inputs. I think it might be a little different. But it gives an idea of what the blade should look like.

---

I looked at the notes I had with the MoI example and it is out of date. I made that before PROP_DESIGN_OPT. So that was the geometry I manually iterated on. Whereas the new geometry was automatically iterated on, so it should be better. However, the MoI example does show how the blade geometry should look in general. As far as the smoothness and quality of the ler, ter, and the blade shape in general. As far as the hub geometry and things like that, the user should make his own based on FEA and their own manufacturing desires. What is in the MoI example is just something I was interested in. There are no propellers that use such a hub retention geometry.

---

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...)

---

Show messages:  1-20  21-40  41-60  61-80  …  221-223