LOL, Actually, I was thinking about doing this. All of my pots on my large servos have 3 pin connectors on them. I was thinking about running them to analog ports as I have multiple ports available. It would allow me to say "hey, you are not in the right place" and tell the servo to move again. It wouldn't be hard to add the splitters that came with these servos to these and use them to connect to analog ports for monitoring. I just have to get time (and money) to get back to this project.

Thank you all for your responses, unfortunately all the posts were directed towards the servos. I only mentioned them as a lead in to my actual question. That is: The question is concerning the getting of the values from the digital and ADC ports. Are those values recieved directly from the ezb when calling a function such as GetDigital(), or GetADC()?

@WBS00001 Those values are, so the answer is yes...GetDigital and GetADC are read values from the ezb....

Just so that we are clear, you can't use GetDigital() and expect to get the value of the pot that is in the servo. You would get a 1 or 0 depending on if the servo is resting or active. This is the reason for the answers that were given. GetADC() would allow you to get the value of the pot based on how much resistance is currently being seen by the pot but this would require the pot to be connected to the analog port.

You can query the analog or digital port as often as you would like. If done too many times or too quickly, you will saturate the bandwidth of the wifi communications link between the EZB and the ARC software. If I remember correctly, this was where you asked the question before. The ARC software would query the EZ-B for these values and return them to you to use in the ARC software. The question originally can from using the WaitForChange command I think. The WaitForChange command doesn't have any delays built in so using it for querying the EZB for changes could be detrimental depending on how it is used.

@Richard R Thank you for your quick response. That's what I thought but, as I have found out, things are not always as they seem. The reason I wanted to know for sure is in regards to traffic on the wireless link between the PC and the ezb. Getting a servo position doesn't require any communications traffic whereas getting a reading fron the Digital and ADC ports does. And does every time they are called.

EDIT @d.cochran Thank you as well. Just saw your post. I guess I wasn't clear in the fact that I wasn't trying to somehow read servo position using either the digital or ADC ports. I can see why there was confusion. Sorry about that.

@WBS00001 you are correct.... since you can't ask a servo to give up it's position there will be "no receive traffic" on the wireless link only sending in order to move it to a position... However, asking the analog or digital port "hey what's up" requires "to" and "from" wifi communication....

All good. Glad you got your answer. I am also glad that you are grasping where things are happening. It sure makes programming a lot easier and more efficient. Good job.

Good responses. The last couple of robots I was using were wheel-type and you would tell it to "move forward" and not usually with a distance nor rotation. Keeps going until you STOP (typically you are monitoring an I/O, like distance, heat, table edge, line on floor, etc). So that probably doesn't really apply here

I've looked through servors.cs and EZB.cs a bit and I see the table (of sorts) of commands (which are colored by increasing their value for the port you want) and then a position/value.

I'm still unclear about what to expect for a response and if it is necessary that I wait for the response and can I keep sending commands on the socket or do I have to close it before they go?

I've written my javascript executioner for a few robots and want to do it for this one as well. It is SO cool to use java script (in a real web page) to control robots...all naturally asynchronous and easy and a full language. If anyone else is interested, that might help incent me to do it for this one as well.

It would be swell if there was a low-level communication guide for this robot (and I dont think it is all that hard to make...not too many commands). I haven't looked at sound and camera yet...those could be more involved.

One more question: I haven't used the builder or the "frame" stuff mentioned, but once you've built frames/actions, what steps through that? Is the host calculating all the motor positions and setting the servos and stepping or is any macro-script sent to the beast?