It depends on the usage. Wait for change is indeed a loop that runs in the background.

This is only based on my understanding and logic...

There is a limited bandwidth to the EZ-B over wifi and the EZ-B has a processor that is many time smaller than the one in your computer. It is easy for your computer to overpower this processor. That being said, the way I use the WaitForChange is that I first think about where the resources are going to be consumed. I dont use a WaitForChange when querying an ADC port for example. I would rather control how quickly the commands are being sent so as to prevent lag with other components. I use a loop with a sleep command to limit this. If the processing is taking place on the computer, for example between roborealm and ARC, I use a waitforchange without much concern for how many resources are being consumed. The PC has multiple processor cores and can easily handle something running in the background without much concern.

I hope first that I understand things correctly and then I hope that I offered an explanation of "depends on the usage".

You got it - it's using wait for change with commands querying the ezb. It's the bandwidth that is the constraint. The ezb can respond and operate very quickly - the limitation is the wifi connection speed and latency.

Using wait for change in just a variable is great and very effecient.

Thanks for taking the time to explain. That makes sense.

Could you give me an example of using wait for change so I can try to understand that concept better?

post 29 on this thread has one

https://synthiam.com/Community/Questions/7667&page=3

This is two applications on the PC communicating with each other over TCP port 6666. There is really no latency here and no real network traffic. This is querying a variable in ARC for a change and not jumping over to the EZ-B for anything.

Something like

:beginofloop
waitforchange(adc0)
if(adc0>100)
do something
endif
goto(beginofloop)

This would be bad. This is where you would want to use another loop instead of the waitforchange because the wait for change has no built in delays. It should look more like this

:beginofloop
$thevalue = GetValue(ADC0)
:waitforchangeloop
if(adc0 <> $thevalue)
do something
endif
sleep(1000)
goto(waitforchangeloop)
goto(beginofloop)

The second would query the port on the EZ-B every second instead of multiple times a second.

**This code is untested and is simply for demonstration purposes.

OK, thanks. I get it.

So the code would be having the Wait For Change command just watch a stated Variable in ARC for change. This command would have to be in a loop with an If statement that would trigger an action when the variable changes. ;)

Dave,

The real difference is where is the processing taking place. If I am just looking for a variable change in ARC, the WaitForChange is great. If I am querying a port on the EZ-B, the waitforchange command isn't so great. The reason is that there is no delay in the command. it will run say 1000 times a second (just an estimate). If I query a port on the EZ-B that many times, what do I gain? What do I loose? The gain would be nothing and the lose would be performance from anything else on the V4. It would saturate or flood the Wifi connection with useless traffic.

If I determined that I want to have this port queried every second as that is fast enough, I would have to insert a delay in the loop. you cant do that with the WaitForChange command, but with a loop and sleep command it can be done. The sleep prevents the wifi connection from becoming saturated to the point that your other ports can't respond to the queries being asked of them.

This isn't an issue with looking at a variable for it to change in ARC. It is within its own application on its own machine with no network latency. It is just hitting memory on your computer which is very fast. Network and especially wifi is the slowest part of the chain. It really depends on where the processing is happening as to what the best use is. As a rule, I would say that if you are querying something on the EZ-B (digital, analog, I2C, Serial, Temp, Voltage...) I would use the loop method. If your doing something within ARC that isn't specific to the hardware on the EZ-B, you should use the WaitForChange.

@David... when you first came on here I think I helped you once sort out a problem you were having with a certain script.... since then you have pretty much leap frogged over everyone on here.... Anyway, thanks (and DJ too) for that awesome tidbit of info. You just helped me streamline my code....

Man this is a great place to learn how to become a robot genius... Richard :)

Richard, Thanks for the kind words. I dont feel like I have leapfrogged but just have a programer background to leverage off of. I would love to have Dave's robot manufacturing skills and a lot of the skills you possess. The thing that I love about the community is that we can all leverage off of each others strengths to all have some incredible robots (along to a huge thanks to DJ and the EZ-Robot team for allowing this to happen).

I also think you helped me wrap my head around what was happening in ARC (along with others here). Understanding is key with scripting and with pretty much everything that we do here. Fear to learn is the thing that keeps most people back. This community doesn't have that fear which makes it a very powerful community.

@David.... no group hug coming :D... You're right, everyone brings something to the table... I did ok writing code for the basic stamp microcontroller and arduino.... But it wasn't until I came here that I "really" learned how to program on a respectable level... It's not just coding, but I learned concepts as well....

Simply put, I personally use WaitForChange when I need the script to wait until something has changed and use Goto loops when I need loops. The clue is in the command :)

For instance, the digital clock I wrote for the LCD display in Melvin used WaitForChange to check the time and update every second but I could have written more code and used an If and Goto loop.

The good code was (simplified to print rather than I2C commands);

:loop
WaitForChange($second)
Print($hour + ":" + $minute + ":" + $second)
Goto(loop)

The same result could be done by checking the seconds using an IF statement and looping until the seconds changed (I won't post the code since it's pointless).

Similar is the RepeatUntil command, this can also be achieved by using an IF statement however it's pointless and more code if you do use an IF statement to loop so many times. If I can save on writing 1 extra line of code I will.

Thanks again for taking the time to help me understand this concept in terms I can understand. You guys are good teachers. David's right, we need each other's skills to make good robots that work like we want them to. ;)

Very Interesting. So all processing for a script takes place on the PC? Like WaitForChange. It is actually a loop running in the background and the processing for it takes place entirely on the PC. Likewise, all the variables queried actually reside on the PC. Is that right? If it is, my question becomes, what changes the state of the variables (stored on the PC) and when does that happen?

I ask because I had envisioned that the V4 was running a process "in the background" (a thread), looking at a variable on board itself and returned a point of data when the variable changes, placing it in a variable in the PCs memory.

Variables are set and changed by script commands inside controls or EZ Scripts within ARC. ARC uses the power of your computer to do the work and sends the command off to the EZB.

ARC is the controlling software and code runs there. There is a connection to the ezb via wifi. The ezb is controlling your hardware devices and waiting for commands to be sent to it from ARC. ARC can retrieve the data from the hardware devices via the ezb. If you set a value from one of these to a variable, that is happening in the ARC software. The ezb doesn't know or care about variables. Image processing is happening in ARC. For example, if you are using face tracking, the ARC software is telling the ezb to move the servos to track the face. It ezb is just sending the data and is responding to the requests to move the servos.

This allows the pc to be used for all of the heavy lifting. The ezb is basically a communication bus. This is why DJ described EZROBOT as a software company. It also allows updates to be made without having to update the EZB. It is also why ARC can run without being connected to the ezb.

What I said.... Be careful David, your teacher is showing. And don't stop letting it show. We'er lucky to have you here on the forum and being so engaged. ;)

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.