You can't execution itself from itself. You're gonna tear a hole through space time.

Why would you not combine the frames of two actions into one single action?

@Dave... If you rip a hole in time and space, you're on your own man... don't look for me for help... I told you not to mess with "the forbidden" scripting....

LOL! You two are a scream! Thanks for the laugh. I really needed one today. I surely don't want to rip the space-time continuum. What if I met my future or past self going through it? Who knows what would happen then.

Anyway, to tell you the truth, I'm still trying to find the best way to move my robot's arms out of the torso without them moving around on the way out and destroying themselves. It's a complicated hot mess. On each arm I have:

*One DC motor moving the arm carriage out of the torso (controlled through the Uart)

• One DC motor moving the elbow joint. (controlled through the Uart) *One additional opto switch that triggers when the DC elbow motor is centered. *Three other servos - Wrist up and down, Wrist right and left, claws.

Only when the arm is fully out of the torso can it begin to move by using actions I made in the AP control.

I have to have the elbow DC motor and both of the wrist servos energized and holding on center before the carriage DC motor takes the arm out of the robot's torso. I'm trying to get as much of this action handled by one AP control as I can. It's proving to be quite an involved job just working through the logic of the scripting behind this and where to place the scripts. I'm ending having to script a lot of this outside of the AP control and calling the actions. I'm using Wait() commands that are watching for variables set when scripts complete.

I did however find a way to call a second action from a first action of the same AP control. I have a script attached to a running frame in action "one" that starts a EZ Script that is outside of this AP control. That EZ Script then starts Action "two" in the AP control. Kinda redundant and messy but it works. sick Again, It's a work in progress and I'm trying to learn the best way to make all this work.

Thanks again for the help.

Would this not do it, put into an EZ-Script control?

# tell the  Auto Position to start the action 
ControlCommand("Auto Position", AutoPositionAction, "An Action 1")

# wait a small amount to ensure the  Auto Position received the message and is running
sleep(500)

# wait for the  Auto Position to set its status variable to 0, meaning completed
waitfor($AutoPositionStatus = 0)

# now that we know the  Auto Position is done with the last action, tell the  Auto Position to start the next action 
ControlCommand("Auto Position", AutoPositionAction, "Another Action")

# wait a small amount to ensure the  Auto Position received the message and is running
sleep(500)

# wait for the  Auto Position to set its status variable to 0, meaning completed
waitfor($AutoPositionStatus = 0)

print("Actions are done")

Ya, I see the logic in this. I was just looking at the $AutoPositionStatus = 0 variable earlier this evening and thinking along these lines. Your laying it out like this really helps to understand the process. Once more, thanks.

Maybe try Blockly for this. You can add the Auto Position actions to a script and the code will be generated that "waits", just like what I posted.

I'm on my phone but I'll whip something up using mobile

Here's doing it with Blockly using the mobile app

Which generates this code

Cool, thanks for taking time to show me how this can help. I've been wanting to sit down and learn how to use Blocky. Sounds like now would be a good time for this. Up till now I've been so involved in getting things working and fixing my bugs.

Does It work the other way also? Can ARC take an ez script and convert it into a Blocky layout?

No, that would be impossible. You can do a lot more with syntax programming than block programming. Syntax programming is far more versatile. Therefore you could not convert syntax to block.