Welcome to Synthiam!

Program robots using technologies created from industry experts. EZ-Builder is our free-to-use robot programming software that makes features like vision recognition, navigation and artificial intelligence easy.
Get Started

Asked — Edited

Waitforchange Command Verses Goto Loop

I remember DJ commenting a few weeks ago that using the waitforchange command takes just a little bit more resources then a loop using a GoTo command. It seems that most proficient script writers here are under the impression that it's the other way around. I thought so too until I read DJ's comment. Did I misunderstand what DJ was saying and the waitforchange command is really most efficient way to go?

Also; if the waitforchange is truly a loop that runs in the background and constantly checks status of the $variable do we need to insert a Sleep command like a GoTo loop to help with freeing up resources?

Any thoughts or answers? Thanks!

Variables are set and changed by script commands inside controls or EZ Scripts within EZ Builder. EZ Builder uses the power of your computer to do the work and sends the command off to the EZB.
EZ-Builder 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 EZ-Builder. EZ-Builder 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 EZ-Builder software. The ezb doesn't know or care about variables. Image processing is happening in ez-builder. For example, if you are using face tracking, the EZ-Builder 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 ezbuilder can run without being connected to the ezb.
What I said.... Be careful David, your teacher is showing. :D 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 EZ-Builder PC memory (simply the last value to which it was set via PWM() from EZ-Builder), 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 EZ-Builder. 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 ez builder.... It is ez builder'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 ez builder....

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 ez builder 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 EZ-Builder in a sense, as you say, by not taking on more of the processing chores. After all, EZ-Builder 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 EZ-Builder 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 EZ-Builder 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 EZ-Builder in both directions then as well. To run without a robot, there would have to be a "Simulator Mode" built into EZ-Builder. A level of abstraction not needed with the current software model. EZ-Builder can run without the robot, but the robot cannot run without EZ-Builder.

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.