Full Version: Anyone wish to develop a custom script?

Show messages:  1-17  …  78-97  98-117  118-137  138-157  158-177  178-197  198-217  218-223

Oops, the trailing edge conic IS slightly different from a trailing edge arc.
Had to zoom way way in...

---

hmm,

i'm having issues with the radius using three point arcs. when i go to fillet it blows up. i'm going to have to work on this a bit more. maybe adjust the points so a two point arc works. i think if you use a three point arc for the le and a two point for the te it will work but haven't tried it yet. otherwise i will adjust the points so you can use a two point arc for both and make it simpler.

edit; after trying a bunch of options including modelling it with the last update of prop_design_geo, i'm thinking the problem might be a smaller te radius. the updated naca file had a slightly smaller radius. when i Boolean union the hub to the blade the te blend is messed up (missing a curve that should be there).

i'm going to try putting the te radius back to the other definition i had and see if that fixes the problem. i will leave the rest of the updated definition in tact, as that fixed a lot of other issues. i want to look at the le points i added too because i'm getting that same error brian found before where the chord is a little bigger than it should be unless you use a three point arc.

update; it wasn't the ter either. i'm stuck right now. the Boolean doesn't work right now. i'm not sure what is causing it. i'll have to get back to you once i figure out what is going on.

update; ok its working. not sure what the issue was. must have been how i was joining the curves or the sweep options. it works with the updated geo. the only thing i want to look at is why the le arc is a little off with the two point option. there is a small error somewhere. i'll have to re-measure and calculate all the points and see if a few are off a little.

---

hi brian,

so i updated the points again. the thing is i'm not sure this is going to make it easier for you or not. it made it harder for me. but here it is for your consumption. it seems like you have to use three point arcs, being very careful to get the end of the rails as the third point. it has a tendency to pick perpendicular and i think that was messing things up. also it may have been the sweep options, not sure. but i went with exact and it worked out. i don't know if refit had anything to do with it. basically when you go to boolean the hub to the blade the trailing edge curve would get messed up sometimes. but this doesn't seem to have anything to do with the points.

as far as the added points go, i kind of like it the other way. but if you have problems going with the conical curve, this extracts enough points that you can just make arcs as the le and te. but for whatever reason the two point arc doesn't work like it use to and i'm having to do a three point arc (for the le at least). for consistence i just did a three point at the te too, but a two point should be fine (as was the case before).

the solid resulting from the sweep seems smoother when you just use the conical tool rather than adding in all the points. you can kind of see where the points are in the solid at some angles. not sure if its real or just an optical thing because the edges of the solid look smooth. in any event, this should be a good fall back option for you if you need it.

updates; once i tried to fillet the blade and hub connection I saw the le was indeed unusual with the added points. they seem to be mucking things up somehow. should definitely stick with the conic section for the le for this data set.

---

Hi Anthony,
""not sure if its real or just an optical thing because the edges of the solid look smooth. """"""""""

A trick i learned from Michael, to rule out "display artifacts" is to do a quick export to obj, then in the meshing dialogue, select "shaded" only, with no edges, then you can cranck up the dicing of the polys, and see what the surface actually is, without some type af display angle artifact... Then just cancel the command to return. FYI

---

Attached is another script, with a conic le, and a 3pt te. (According to MoI docs, the conic is a portion of an ellipse.)
The apex of the conic was hard-coded, based upon MoI previous distance measure of it's z coordinate.

The attempt to join the 4 curves, non-interactively, was not successful. Join factory created duplicates of the 3 non-mirrored curves.
Seemed like the mirrored curve factory did not .calculate the Object list. (?)

Without the non-interactive join, it is just as well to let the user interactively add the conic.

I think that is about it, for this project...

Attachments:
PropDesignGeoA1_6_2012.7z

---

Thanks burrman,

i think they were real because when i went to do the fillet of the blade to the hub the le was all weird. so adding the points doesn't seem to be a good thing in this case.

---

thanks brian,

i give it a spin.

update; script works great, however, the html files you provide are both the wide version.

update 2; spoke two soon. when i overlay the prop_design_geo output to your script it appears you still have the airfoil splines as control point curves. they can now be made through points (due to the change in naca reference file and the conic section curve for the le).

---

i found this online, its pretty interesting. could be how they made an ellipse in the old days. not sure. i vaguely remember doing stuff like that as a kid.

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

i think Steven's Method is more of what i'm looking for though:

http://mysite.du.edu/~jcalvert/math/ellipse.htm

---

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

---

Show messages:  1-17  …  78-97  98-117  118-137  138-157  158-177  178-197  198-217  218-223