Thank you for your responses. I believe I see now.

I wonder, do instructions such as GetPWM() come from the ARC PC memory (simply the last value to which it was set via PWM() from ARC), or do they come from the ezb itself? It seems like the ezb would need to store such values somewhere to refer to each time it moves the servo. Same for GetServoSpeed().

Don't quite get things like WaitForChange(GetServo(d0)) - an example in the Script Manual. Since you can't read the position of the servo from the ezb, that would mean all you are doing is reading the last set value of some global variable in ARC. It will only change when another servo instruction of some form is sent. Thing is there will be no instructions sent until there is a change. So it's seems to be a catch-22. The script would never move on.

@WBS00001 Think of the ezb as just a messenger or if you will puppet controlled by ARC.... It is ARC's eyes, nose, ears, mouth and touch.... if PC's were small enough and had the massive IOs that the ezb4 has, then you wouldn't even need an ezb....

This particular WaitForChange(GetServo(d0)) example you gave might be useful if you have one script controlling another without actually having to reference that script directly or even by name... Here's an example.... say you had a main controlling script that moves servos for your robot.... You then created a second script that runs continuously in the background waiting for servo movement changes before executing. When your main script tells a servo to change positions this will trigger WaitForChange(GetServo(d0)) in your background script to run.... As mentioned you can't actually read servo positions directly but you can read referenced movement changes within ARC....

Remember think "multitasking" when you think of the way the ez robot software and ezb work.... This is one of the main reasons ez robot so much more powerful than other robotic platforms.... As David mentioned it is all about the software.... If fact if anything it is the ezb4 that is the weak link in the chain here... I am not saying there is anything wrong with the ezb4 as it still is the best robot controller in the world, but it holds back ARC in a sense.... This is because the software is so outstanding... If DJ sold his entire inventory and circuit design for the ezb4 he would make thousands.... If he sold his software he would make multi millions.... Anyway, you will get that eureka moment soon enough, trust me...

@Richard R. Thank you for your explanation. Yes, it makes sense when you are running multiple scripts simultaneously. One waiting for the other to move the servo.

The ezb does seem to hold back ARC in a sense, as you say, by not taking on more of the processing chores. After all, ARC could, it seems to me, cause a thread to be spawned in ezb (which runs in ezb) that waits for the servo to change and then sends data to ARC when it does. No script looping required, and no danger of overloading the communications link. I suppose though, that would go against the philosophy of the ezb being only a controller and the ARC program doing all the higher lever brain work, including keeping track of where the servos are supposed to be. There would have to be closer coupling between the ezb and ARC in both directions then as well. To run without a robot, there would have to be a "Simulator Mode" built into ARC. A level of abstraction not needed with the current software model. ARC can run without the robot, but the robot cannot run without ARC.

Still, it would be fun to try to run your own side programs in the ezb, but we don't know enough about the architecture of the ezb as a whole to readily do that.