Before :Start or in a separate Int script you run first you might want to declare it as follows:

$Associate = "0"

But do you know why you need to do that? It's a good idea to declare all variables upfront with default values before they are used.

You don't have to declare a variable but you have to assign a value to a variable... Just put $Associate ="null" or $Associate =0 or whatever at the beginning of your script.... You have it = y... but does y have a value?

Y is the value he is settings, he is settings Y and N values for the $Customer and $Associate. You need set string quotes around all the values you are setting variables to, like this:

$Associate = "Y"

And you also need to make sure what you set is the same value, because Y is the not the same is y. Lots of little mistakes.

Here is your script with the corrections needed:

$Associate = "null"
$AssociateGreeting = "null"
:Start

# check for motion
if(getDigital(D18)=1)
Print (" associate detected")
$Associate = "Y"
$AssociateTime = $time
sayEZB(" I SEE a associate")
sleep(3000)
endif

if(getDigital(D17)=1)
$Customer = "Y"
$CustomerTime = $time
Print ("customer detected")
sayEZB(" I SEE an Customer. ")
sleep(3000)
endif

# Lets see if we need to greet associate 
if($Associate = "Y")
 if($AssociateGreeting = "N")
 $AssociateGreeting = "Y"
 # turn head to look in associate direction LEFT
 Servo(D0,135)
 Servo(D1, 100)
 print(" Greeting Associate")
 if($customer = "N") 
 $x101 = GetRandom( 1,7 )
 if($x101 = 1)
 SayEZBWait(" sIR ")
 elseif ($x101 = 2)
 SayEZBWait(" HELLO SIR ")
 elseif ($x101 = 3)
 SayEZBWait(" hello ")
 elseif ($x101 = 4)
 SayEZBWait(" Hi")
 elseif ($x101 = 5)
 SayEZBWait(" hi there ") 
 elseif ($x101 = 6)
 SayEZBWait(" back a gin sir? ") 
 endif
 $x101 = 0
 else
 $x101 = GetRandom( 1,7 )
 if($x101 = 1)
 SayEZBWait(" Sir can you help this costomer? ")
 elseif ($x101 = 2)
 SayEZBWait(" HELLO SIR this costomer needs your help ")
 elseif ($x101 = 3)
 SayEZBWait(" hello sir, we have a costomer ")
 elseif ($x101 = 4)
 SayEZBWait(" Sir we have a customer who needs your help. ")
 elseif ($x101 = 5)
 SayEZBWait(" Sir we have a customer ") 
 elseif ($x101 = 6)
 SayEZBWait(" Customer sir. ") 
 endif
 $x101 = 0 

 endif 
 # face forward
 Servo(D0, 90)
 Servo(D1, 100)

 endif
endif

goto(Start)

Just an additional note for the future. Variables are global across scripts, so if you set it in one script, you can use it in another. This means you can initialize all of your variables in your init script, and you can use data learned in one script in another. It can be bad because if you used a variable in one script and use the same variable name in another script but intend for it to mean something else, you can get unpredictable results.

To be sure not to have that happen, I initialize all of my variables in my init script, but that is just personal preference.

Alan

This tutorial may be of use to you: https://synthiam.com/Tutorials/Lesson/23

Thank you all for the information. I love the idea that variables are script wide. That's really useful. Thanks JustinRatliff , thetechguru and DJ for all the help. I went and looked over the tutorial DJ suggested and learned a lot. Thanks.

Awesome That's what this forum is all about!

@Slee The Sloth The biggest eye opener for me when I was first started with ez robot was the moment I realized that the ezb (ARC) was a true multi threading controller.... I know the arduino can use interrupts but that can be hardly called multi threading, really.... I came from using the Basic AtomPro micro controller (similar to the arduino) and I was pretty much at the end of the "what else can I do with it" cycle.... I had projects in mind that would need either 2 or more micros in the project or a true multi tasking controller.... then ez robot showed me a new path.... LOL

Slee, I just wanted to make sure you knew that many scripts can run at the same time. Each of these scripts use a thread and can be called by other scripts. All scripts share the same variables so values can be passed between different scripts.

This is what Alan and Richard are talking about. You made a statement about variables being script wide. I just wanted to make sure you understood.

Richard R , Yes my once beloved Arduino is vary single minded and can only handle one task at a time. While the current project I'm working on is not integrating EZB4 into my full sale R2, it is the learning point that is preparing me for the R2 integration project. I do really wish I had known when I first started to build my astromech (R2D2). But as it stands I'm building an associate droid. His job will be to great customers when they come into my small computer shop. This will give me a bit more time to get to the customer area.

d.cochran, Being able to run several scripts and have them share variables is the difference between night and day. Now all we need is an expansion board for more pins. But I'm thinking I can get one EZB-4 to talk to a Arduino mega 2560 via serial. Then the EZB-4 will be the brain and the mega 2560 will be a slave. This will make my later project ( When I integrate the EZB-4 in to my existing R2D2's systems. But for now I'm using my associate droid as a learning point so I do not bugger up my R2. I will tell you that when I purchased my EZB-4's I got 3 of them and 2 cams. I have already mount the second EZB-4 in R2 already, its just not hooked up. While my R2 works just assume as it is. It is nothing more the a big RC toy. EZB-4 will give it autonomous functions when R2 is not in RC mode.

So Thanks for all the help guys!

My associate droid named Droid-Mun: https://www.youtube.com/watch?v=zvnVki1lYF0

My astromech droid R2D2: https://www.youtube.com/watch?v=UcoBHKIsNrY

Hey Slee, based on your comments, I want to make sure that you understand.

ARC can control multiple EZ-B's which you know.

ARC can run multiple scripts at the same time, which you now know.

These scripts can run at the same time for the same EZ-B. This is the part that based on your statements I don't know you are clear on.

In the arduino world... you write code and dump it to the arduino which loops through that code and does what you have told it to do. The arduino is a single threaded processor and can only do one thing on each clock cycle of the processor. You can split up those cycles using some tricks but only one thing per cycle can be done.

In the EZ-Robot world, your computer is the brain and can do multiple things on each clock cycle based on the number of cores your computer processor has. This is commonly a minimum of 2 and sometimes up to 128 if you are running on a huge server (actually now there are some that are higher than that). Most of the time it is 4 to 8 for consumer grade machines. ARC is a multi-threaded application which allows the use of these cores, and handles the logic needed to handle many more threads. I am not going to explain how this works as it is far beyond what I am trying to convey.

Lets say you want your robot to monitor its battery level, follow shapes and play some sounds at the same time. In the arduino world you would have to have it do this in a linear approach. It would do one thing, then do the next then do the next and then repeat. In the EZ-B world, you could start a script that is in a loop that monitors battery levels, start another script that follows shapes and then another script that plays sounds. All three of these could run at the same time. Now you could communicate between these scripts. By setting a variable in the script that is monitoring battery levels to something like $BatteryLevelIssue = 0 then the other scripts could just check the $BatteryLevelIssue in an if statement to make sure that it is not set to 1. If it is set to one, you could have these other scripts exit the loop that they are in and stop.

This is a different mindset than the arduino and one that is a bit difficult for some to grasp that are used to the arduino. I use arduinos for things like running a bumper sensor array and converting that data back to the EZ-B via serial. If there is something sensed by the arduino driven array, it alerts the EZ-B over serial which is being monitored by its own script. This script is doing nothing but looking for a serial feed from the arduino that would indicate that there is something in the path of the robot and setting a variable to let other scripts know which of the bumper sensors has been tripped. The other script uses this information determine what needs to happen to have the robot get a clear path to travel. Now, compass and other sensors could be employed and used by the V4. These could be used in the same script or in other scripts which can communicate with each other using variables. The compass could always be being read by the V4 or you could just start the script that reads the compass when you need a heading. This reading could be gathered by a script which would be setting a variable called $heading. The other script could use the $heading variable along with the bumper alert variable to then decide which direction (in degrees) the robot should move. Another script could then be called which would turn the robot to that degree (using the heading variable which is changing from the compass script as the robot turns). This script could report back to the navigation script that it has completed or simply set a variable saying something like $amnowincorrectdirection = 1 which the navigation script would be waiting on before telling the robot to continue to move forward.

This is an example that could then do so much more, but as you can see, the use of multiple scripts can become quite powerful. Also, having one script do one and only one thing and do it well allows you to then segment and test your scripts. Having a single script run which does everything can become quite difficult and it will be single threaded, which hurts the power of the platform you have to build on.

If you already understood all of this, great. If not, great. I just wanted to make sure you got what was being said.

d.cochran,

Thanks. I'm on the same page now. Thanks