@DJ Sures Well, as I see it, using the autopositioner is fine, but not very flexible. That is to say, the results from it are fixed and does what it does the same way every time you run the frames. And that's fine for things like the getting up task. That's a complex operation and will probably be the same every time you use it. Still, If you want to change anything, no matter how slight, you basically have to go back to the autopositioner software control to do it. Also fine by me for some things.

To me, the finger movement under discussion is different. Using autopositioner I can get it to open or close, yes, but, if I want something in between I have to go through the process of moving each finger in the AutoPosition setup to where I want them to be or move to. Then have it generate the script code for that particular sequence. Create a frame and group frames as needed, etc. If I want a different position, I have to do the same thing again. With the example I gave I can set the fingers of the hand to any position (not just full open or full close) with just two lines of code.

Now I'm a neophyte here and I understand that and there are ways to use autopositioner of which I am not aware I'm sure. I don't mean to step on any toes, I just wanted to see what others thought of that method. And to find out of it will actually work as described. Still don't have a JD yet so I can't test it out for myself, so I threw it out there.

@Rich Yes, you're right. Moving the "MoveAllFingers" to after the the calling section instead of before it would be better for this simple example. But I look at the MoveAllFingers routine as something that would be called many times in a given real program. Making sure it is always at the end of the main program sequence would become tedious every time I add to the overall program. Putting it up front eliminates that problem. The same for other routines I would call from several different points on the overall program. I would declare them all up front first. Generally makes it easier to add new such routines as well. Plus, what the hell, it's habit for me to do it that way.

Likewise with the variables I would use in the program. I would declare them up front to make their initial declared values easy to change. I usually add many variables to use as constants as well. For instance I would declare a variable for each servo and use that variable throughout the script as opposed to directly using the servo port number. That way if I change the port for a particular servo all I have to do is change that value in one place.

@WBS ALWAYS THE HARD WAY!

May not be the hard way. Just a different way, IMHO.

I tried Steve G's code and of course I added min and max servo settings at the top of the script and it worked like a champ! I also liked the code that allowed the fingers to move at a slower speed. That was a pretty cool effect. Next, I will try Bob Houston's and Aerius's and Richard R and Dj's advise with Auto Position control. I also have to figure out how to tighten the braided fishing line as my fingers are not tight enough. I'm sure there is an art to it.

Thanks guys! BobJ

@merne Perhaps hard to you, the familiar (and correct) way to me. It's also easy for me because I've done it that way so much. I'm assuming you're referring to the post just above yours. Granted it's also more initial work, but the practices I employ pay dividens in the long run when you want to make changes or additions. Heck, wait until I bring forth the Object Oriented version of the Scripting language! {Kidding ... I think}

@WBS, in that case, have you looked at using multiple scripts and ControlCommands? Look at the latest Ping Roam script of mine (in the cloud) for an example of this. Multiple scripts or sub-routines called by a main script (or the sub routines). It made it even easier to make changes or use the same section of code multiple times.

@Rich Thanks. I wondered about that. That was going to be the next thing I looked at to see how all that was usually done. I'll start with your example. Does seem like a good way to isolate program sections for reuse. Also perhaps a way to introduce "scope" into the whole thing.