Full Version: Anyone wish to develop a custom script?

Show messages:  1-9  …  90-109  110-129  130-149  150-169  170-189  190-209  210-223

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.

---

Hi Anthony,

Sounds like good ideas. I'll study on it a bit.
After our bad ice storm, puget sound region, Washington state, power is on again, but no internet at home yet :-)

---

Sorry to hear that. I've been through a few of those. No fun. Especially when your neighbors have power and you don't, lol. I was lucky that my gas fireplace worked for some reason, even though there was no power and there was no battery that powered it. So at least I didn't freeze to death.

I am working on an update to PROP_DESIGN. When I posted that file for you to use, I saw the examples I have were still not quite in sync. So I have been working on getting them the way I want. This shouldn't affect anything you have done or may do in the future. I should have the latest version uploaded in a few hours.

---

hi,

i'm back after many years away. my posts say unknown users, since I had Michael delete my account. at the time I started this thread I was evaluating moi v2. I ended up going with rhino because I thought it would be more inline with what PROP_DESIGN users may have wanted. however, after many years of using it, I have grown tired of the constant battle to get it to create valid solid models. when rhino 6 came out and the users panned it, I looked at MoI again. Everyone was raving about MoI v4. So I decided to make the switch to MoI. I had thought that since rhino worked with PROP_DESIGN xyz files out of the box and that there was a large amount of 3rd party plugins, rhino would be the way to go for most PROP_DESIGN users. However, the plugin community has pretty much died and MoI can work with xyz files. So I have already been recommending MoI for awhile now, instead of Rhino.

I am still making the blade models manually. Which can take a really long time. The worst part is the last step sometimes will never work. That is making the root fillet. It would often break the model in Rhino. Oddly, it's a model by model issue. Some models have no problems. Others you can fight with it for awhile and get a valid model. Other models will never make a valid solid. So it's nothing I am doing, as far as I can tell. I will be interested to see how MoI does. It can't be any worse, so I figure what the heck.

In any event, if anyone has spare time and would be interested in trying to completely automate the creation of solid propeller/fan/turbofan blades, let me know. I think this would be a very useful thing for a lot of people. If a blade model can be created automatically in a second or two. That will save at least an hour per blade model, if not more. That adds up over time. I made a video showing the issues involved. The main thing is I want to be able to read in the xyz files and then have a dialog to select what sort of profile you want to use. Then have the model created. The blade count would need to be known as well. This would be a very involved task. I don't know for sure if MoI can be automated to the extent needed. I just figured I would ask. If no one can do it or is willing to do it, that's ok too. I'm just glade to never have to use Rhino again. What a kick to the shorts that was.

The video talking about the things involved with the automation is here; https://www.youtube.com/watch?v=R5DF822U89w&index=2&list=PLzGiietqAECXnIFl6ngHvhzgBxgTrC_qW&t=0s

If you want to know about the version of PROP_DESIGN that makes the xyz files, that video is here; https://www.youtube.com/watch?v=jco0EqEa8Jw&t=0s&list=PLzGiietqAECXbwWGhodSW6Lni51Tj8Q_U&index=6

Also, note that there was many changes to PROP_DESIGN since bemfarmer recoded the xyz portion. So they would no longer be the same. I'm more interesting in the blade creation past the xyz files though. There isn't a need to recode xyz.

Sincerely,

Anthony Falzone

Developer of PROP_DESIGN
Public domain aircraft propeller/fan/turbofan design and analysis software
https://propdesign.jimdo.com/

---

Welcome back Anthony.

- Brian

---

Show messages:  1-9  …  90-109  110-129  130-149  150-169  170-189  190-209  210-223