I'm trying to script a non-interactive arccontinue. Also trying to script a non-interactive conic, which seems to invole similar problems.

The documentation of Dave Morrill does not mention conic, and for arccontinue, just mentions start and end points, without the curves.

The points need Bind or Snap to the associated curves, which I have no idea how to do non-interactively.

Somehow pointpicker gets bound to 4 conic factory getInputs?

Conic getInput(0) ........Start point.
Conic getInput(1) ........End point.
Conic getInput(2) ........Apex point.
Conic getInput(3) ........Through point.
Conic getInput(4) ........rho value.

Hi Brian - I don't think it will work to make a non-interactive arc continue, since the arc continue factory is set up to work with an osnapped point as its first input.

That's another variety of point (IMoiPickedPoint) that is generated by the point picker, in addition to containing an x,y,z point in it it also contains a list of snaps that were active for the point, and the arc continue factory finds the curve to be tangent from by going through those object snaps.

There is not currently any way to set up a "picked point" other than having it generated from a pointpicker pick, so I don't think that is one that you will be able to automate currently.


Conic should be possible to script though - the inputs what you wrote, you need the first 3 inputs set to points (these can be regular x,y,z data points), then set either the 4th input (with index = 3 since they start at 0) to a point for the "through point" or instead of that you can set the 5th input (with index = 4) to a rho value which is a floating point number.

If you want to specify a "through point", then leave the rho value completely unset, and if you want to specify a rho value instead then you can leave the "through point" input completely unset. Let me know if you still have problems with it.

- Michael

also, if worst comes to worst brian I can add back in the tangent points and you can do the le arc as you were. i would have to add in a bunch of other points though to fill out the conic part of the curve. but its not that big of a deal, if you hit a road block with the current method.

Thank you very much Michael.

The arccontinue did work nicely on the trailing edge, interactively. Instead I'll measure the distance with MoI later, and
do 3pt arc instead.

The conic is a pretty neat curve for the leading edge. I'll try later to see if I can locate the tantan point.
Or just interactively find out the rho value, and then use that in the script... "simple"...

Edit, the le rho value is stated by MoI interactively, as 0.42609.

I was working on a new version for PropDesignGeo, January 5 2012, dropping a lot of "unnecessary" points, with conic le, and arc te, and
fixing up a join factory which I hope will work...

Got a trailing edge rho value of 0.0952.

The trailing edge arccontinue, and a trailing edge conic,
EDIT: are ALMOST the same. Need to zoom WAY in to see slight difference.

Leading edge arccontinue is different curve from le conic.

hey brian,

in case you run into a wall with the last version of prop_design_geo, I went ahead and added a bunch of points to the data set so that you don't
have to use the conic section.

edit; a later post replaces this one.

brian,

i see you said you got a trailing edge rho value. you should only use the conic section for the leading edge. the trailing edge is still done with a circle. in fact the leading edge is also done with a circle. however the conic section defines the transition from the circle to the naca points and it also overlays the circle at the leading edge.

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

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.

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