Welcome to Synthiam!

The easiest way to program the most powerful robots. Use technologies by leading industry experts. ARC is a free-to-use robot programming software that makes servo automation, computer vision, autonomous navigation, and artificial intelligence easy.

Get Started
Asked — Edited

Goto Last Loop Variable Goto + Variable Goto($Variable)

Has anyone figured out way to get the goto() function to work with variable so it can goto the last defined loop such as this :


 $lastLoop = ""

$last = "loop1"

left(200, 0)



this would allow to have the equivalent to calling a function and resuming the current loop after its execution. It would prevent me from using too many scripts and avoid lots of redundancies. My project currently has 50 scripts so I'm trying to find a way to shrink this number. :P


Upgrade to ARC Pro

Get access to the latest features and updates with ARC Early Access edition. You'll have everything that's needed to unleash your robot's potential!

AI Support Bot
Related Content
Well - that's a complicated question! Now you've opened up a big can of whoop...

So here's the thing - an arduino, an ez-b, a PC, etc... are all not multitasking controllers. This is because CPU's are not multitasking. What _is_ multitasking is software. If a CPU has more than one core, the multitasking of software utilizes the cores for "threads". Or, if there's only one core, the operating system uses interrupts with process priority and executes each "task" as a thread (i.e. a few instructions of each task at a time)

Threading programming has traditionally been a frightening place for inexperienced or over-confident programmers... and a scary place for security vulnerabilities as well. This is because even though software runs on top of hardware, there is no easy way to synchronize states.

There is another thread, started by the same poster as this thread which we hijacked, who is having issue with his camera. The issue is hardware related - or outside of ez-robot's control. The hardware can either be the network, a driver, a usb cable, etc... This is because even though software runs on hardware, it is dependent on the assumption that the hardware is performing 100% as expected. Hardware bugs is why software can suck, specifically in a threaded environment. Take for instance a driver loading in windows for a hardware device - the software can only assume everything is working as programmed.

Secondly, on the topic of the dangers of threading, is data synchronization. Meaning, when an operating system is running threads on multiple physical cores, how does each software thread know how to synchronize its state and when is the data in a specific memory address valid or not valid? Who's writing or reading to that memory? What core? What thread? What if two threads on different cores are attempting to read/write to the same memory? Who monitors it? What if the monitor is on a different core and thread? How do you trust the monitor...

So with this huge chunk of confusion - now i can introduce how ez-robot does things. First, we assume the operating system and runtime environment knows how the heck to handle threads, which .Net does very well (in it's own way, which we override with our own task scheduler). So ez-robot has our own task scheduler, and it is lighter weight than the microsoft one, and also specific to our needs. EZ-B.DLL and ARC.EXE both use the task scheduler.

Each control runs in a separate thread and uses the task scheduler to ensure only one of itself is executing at a time. This means multiple controls can run at once, but only one time per control - if that makes sense.

Here's something that you don't get to see. This is the debug output of the EZ Task Scheduler when loading the JD Example Project. See how many tasks are loaded...


EZ Task Scheduler Initialized: v4 Video
EZ Task Scheduler Initialized: Auto Position: fe0a73f6-d4da-4602-82ee-2c7e28cad869
EZ Task Scheduler Initialized: v4 Sound Progress
EZ Task Scheduler Initialized: v4 Sound
EZ Task Scheduler Initialized: Auto Position: 1c9387e7-11d2-4bfa-a656-43e27e717166
EZ Task Scheduler Initialized: v4 Sound Progress
EZ Task Scheduler Initialized: v4 Sound
EZ Task Scheduler Initialized: Auto Position: e018f951-b15a-4eb4-8d2f-93e1f621d191
EZ Task Scheduler Initialized: v4 Sound Progress
EZ Task Scheduler Initialized: v4 Sound
EZ Task Scheduler Initialized: Auto Position: e19a8c50-574d-479a-bb9d-90731b6358b3
EZ Task Scheduler Initialized: v4 Sound Progress
EZ Task Scheduler Initialized: v4 Sound
EZ Task Scheduler Initialized: Auto Position: 43b7610d-84df-49f1-807e-084b33b38304
EZ Task Scheduler Initialized: v4 Sound Progress
EZ Task Scheduler Initialized: v4 Sound
EZ Task Scheduler Initialized: Init
EZ Task Scheduler Initialized: e87b5001-9d76-47d5-83e2-94226cc80dbe
EZ Task Scheduler Initialized: 15610d79-6037-4f0e-b8be-d0f5af6c4cf2
EZ Task Scheduler Initialized: f1060ce3-885b-4de5-acc1-ecb90dd191c9
EZ Task Scheduler Initialized: 1788a0ab-b550-4210-9671-a4a992c093b1
EZ Task Scheduler Initialized: 5743ed5f-82f7-45f9-91d5-c85e74487c19
EZ Task Scheduler Initialized: ec07164c-ab5f-4bf3-afe2-1f8ac8697696
EZ Task Scheduler Initialized: c0b44a47-d076-47d1-a894-8e50a5c7975d
EZ Task Scheduler Initialized: 01b32271-8cab-49c1-a284-0f172c0d4808
EZ Task Scheduler Initialized: 398794c5-a1b9-4a97-93f3-9bbb5c5133ad
EZ Task Scheduler Initialized: e1a9bfd8-5688-4034-b782-de470bd18ebe
EZ Task Scheduler Initialized: 391b195c-8142-4d17-94a0-86d1ee69770a
EZ Task Scheduler Initialized: b2f1742d-8ed5-4b19-bda6-0e8ecc000f41
EZ Task Scheduler Initialized: eb4fe56c-9d33-4ae9-9580-a6fbfbb66338
EZ Task Scheduler Initialized: 809baa1b-0438-4cb0-b767-098e8d4b3135
EZ Task Scheduler Initialized: 3c38fd06-fc2d-4f07-968c-ee73678c9510
EZ Task Scheduler Initialized: 72add477-3ebd-4394-bf7a-6ddc0843e3cd
EZ Task Scheduler Initialized: 31e94017-eb1a-4755-bb32-49c05fcf1ece
EZ Task Scheduler Initialized: 8adcf783-8439-43bf-9485-1a9593f1d7dd
EZ Task Scheduler Initialized: 8debbbe3-6d6c-4cf9-8250-e091312eff78
EZ Task Scheduler Initialized: 01dbec08-c55e-4eff-a68d-e242e5130f87
EZ Task Scheduler Initialized: 99319c0e-a46a-4fbf-bd83-75bfe70c0885
EZ Task Scheduler Initialized: 3b026b66-87d3-486e-889a-36b7b1120910
EZ Task Scheduler Initialized: 7ef28e69-0e6f-4ef7-9d59-e1303e37b911
EZ Task Scheduler Initialized: c8fd4f42-5e25-48aa-8078-4dfe704ee509
EZ Task Scheduler Initialized: 33ec792c-e7eb-4e9a-a195-cc5261270b00
EZ Task Scheduler Initialized: dc6d0a90-1f37-4132-a0c1-31775aa111fb
EZ Task Scheduler Initialized: e37936ae-3b0e-427d-9f8f-c80d77e9549e
EZ Task Scheduler Initialized: 7aa2621e-4921-4edb-86fa-1f43d095d2b4
EZ Task Scheduler Initialized: f13e410e-7446-4419-ae08-c2672dbdf2ee
EZ Task Scheduler Initialized: bdfd33b4-65fb-4134-9898-565b6115840c
EZ Task Scheduler Initialized: 90ae8655-ec7e-417f-8972-a27966b8099d
EZ Task Scheduler Initialized: 245ea96a-8c43-46c8-98a5-31eaf2a21440
EZ Task Scheduler Initialized: 33a5f358-3d8d-436e-9306-eac2d1330d11

Because they're all talking TO and FROM the EZ-B, now we get into the communication side of things...

The communication protocol of the EZ-B is buffered synchronous - meaning commands are sent and received FIFO in a linear fashion. All the kids line up when the bell rings to enter the school.

The buffered side of the synchronous introduces threading. To reference the multi cpu core bit above, the ez-b communication protocol synchronizes the EZ-B to the PC's EZ-B.DLL communication channel, which in-turn connects to the appropriate EZ Task.

So the communication channel is not "threaded" because it is buffered synchronous FIFO - however, once the data is in the EZ-B, it's handled in threads again.

The EZ-B has 2 microcontrollers, and 1 for the camera, and other peripherals have their own as well. So let's just reference the EZ-B micros to start...

The first micro on the EZ-B that "talks" to the PC and buffers the FIFO is Wifi module. All versions of the EZ-B Comm Board use a real-time multitasking operating system (RTOS). The latest EZ-B (v4.x/2) has a very advanced custom RTOS, made specifically for EZ-Robot. The RTOS has a bunch of threads that are separate processes. You can telnet into port 8080 of the v4.x/2 and view the tasks that are currently running.

You will see a bunch of processes...

User-inserted image

Each process is a thread on the CPU. The processes are little "programs" that perform a function and share data with mutex locks, etc.. You can see how there's processes for the HTTP Server, CLI Server, Clients, Network Broadcasts, etc... These are all separate threads making sure the communication between the EZ-B and the PC works and is buffered. This is why the v4.x/2 is so friggin awesome and reliable - using dma with software/hardware buffers and monitors and mutex locks and a pile of other stuff. It's 380k of compiled opcode that makes the next gen ez-b an entirely new beast.

Now, we're talking about the top CPU on the EZ-B. There is another CPU on the EZ-B which is on the bottom board. And that chips is actually the EZ-B. It's got a lot of code on it, which does a lot of things. It runs very specific code that "listens" for commands - while it bit-bangs ports and buffers data in it's hardware dma. The OS on this chip is not "multitasking" at all - however, it does a bunch of things at the same time using hardware timers and DMA. It understands things like the Audio CODEC and servos and pwm, etc.. all in software. Because while micro's traditionally are limited to the number of PWM hardware peripherals for servos, i have very efficient code that i wrote 4 years ago which bitbangs PWM and ramping on 24 ports, dynamically.

To answer your question in a summary...
1) OS is threaded
2) ARC is not threaded
3) ARC controls are threaded
4) EZ-B.DLL functions (rgb animator, auto positioner, audio player, video, etc) are threaded
5) EZ-B.DLL Comm channel is buffered synchronous FIFO
6) EZ-B v4 Comm CPU is threaded RTOS
7) EZ-B v4 Main CPU is not threaded but performs many functions at once using hardware timers and dma

I guess the short answer is that the "threading" or "processes" are distributed across a variety of physical hardware - including both the EZ-B and various software on the PC.
First off to the OP...again apologies for the thread hijack...again... @DJ... Very nice and detailed explanation, I got chills LOL :)... I understood about 95% of what you wrote. One has to really appreciate the amount of work you put into not only to develop the ezb and ARC but the continued updates you have been giving us... I am really looking forward to using the upcoming ezb4.1/2 in my projects....
@RichardR I found this site by doing a search after purchasing a Walmart R2D2 shell. I have sense purchased the developers kit and made numerous trips to Radio Shack. While Building, I managed to lose the camera cable so I am waiting for a replacement on that. I will post pictures and video soon to the Robot Showcase.:)
@elfege: Sorry to hijack your thread


Thanks for explaining the hardware layers,
Q1 i'm assuming the communication between ARC and the EZB is only one way, there are no callbacks right ?

When a servo command is sent with a specific speed/pos, there is no way no know if the servo is still moving or not,
Q2 it's not possible to implement a firmware call (plus a script command) to obtain (polling) the servo status per port e.g. (no servo, attached, moving, detached, etc?)

That could help to avoid sending a release while the servo is still running. There a thread discussing the issue.

Q3 It's feasible to expect firmware updates for the existing boards (EZB4) ?


Q1 i'm assuming the communication between ARC and the EZB is only one way, there are no callbacks right ?

When a servo command is sent with a specific speed/pos, there is no way no know if the servo is still moving or not,

That is the nature of Servos, not the EZ-B. The EZ-B is two way communications. You can read an ADC port, a UART, an I2C, and see if some other device has set a digital port high or low. You can't get the position of a servo from the servo, because they don't have any way of telling the EZ-B their position (Dynamixel's theoretically can, but are poorly documented so DJ didn't build the function into the plugin, but the plugin is open source, so anyone else can tackle it if they are up to it).


Q2 it's not possible to implement a firmware call (plus a script command) to obtain (polling) the servo status per port e.g. (no servo, attached, moving, detached, etc?)

See answer to question 1.


Q3 It's feasible to expect firmware updates for the existing boards (EZB4) ?
Not through software directly, but see http://synthiam.com/Products/ARC for link to the required tool and instructions. Simply flashing with the downloaded file brings the EZ-B up to the current version, most importantly fixing the DHCP "bug". You can also modify default settings and change the EZ-B's web page.

@PTP...No Information to the ezb is 2 way... Pings for instance send their data back to ARC. Hobby servos are one way communication only, however... Their internal pot is used by the servo's control board to control servo position. This information does not go back upstream....However you can hack any servo and run a wire from the pot to an analog port which would them provide the controller ( the ezb in this case) position feedback.... There are servo's like Dynamixels that provide position feedback to the controller. ...
i m on the phone but not driving;)


I know the difference between a servo with feedback and no feedback. I also know the servo does not have speed control so the speed control is done by software my guess is firmware so the ARC sends a command like goto position x with speed y the firmware accepts the cmd and behind the scenes is looping from current position to position y with a specific speed, while doing that ARC/scripting does not know where the servo is (position) because there is no call back from the firmware to the ARC

So my question is why not implement a firmware call to ask the current servo status that away is 100% clean knowing where the firmware is doing
@richard what i mean only one away is the ARC call the eZb and not the other away arround.

For example i dont think the firmware (ezb) will notify the ARC when something is done but is a guess (otherwise you need to open tcp ports on your windows and all the support issues related to that)

So i know you can query a ping, poll image etc but the communication starts and ends in the ez side

Unless there is always a connect connection initiated by the ARC and the firmware uses that channel to send notifications

DJ knows for sure i m only guessing.
DJ, your a code god! You all can hijack any thread of mine at any time if it's as useful as this.

So, as far as threading, will my robot project running on ARC take advantage of multiple cpu cores? if I have a large project with many controls, loops ,audio streaming and adc checking going on will more than two cores help? I do understand that there are other things happening also to control the traffic (thanks to DJ's amazing discription). However in supported os are extra cores used?

Also, it sounds like it's better to have many controls called from one script for different functions then having one script handling them by it's self?
Ptp, there is no fredback from a servo, which had been repeated. Please read the how a servo works tutorial. Herr is a direct link for your convenience: http://www.ez-robot.com/Tutorials/Lesson/48?courseId=6

Callbacks cannot work for a servo. Callbacks only work for specific commands, such as repeated in this thread. Also, your definition of a callback is performance limiting.

I explained in detail, but I'm time constrained to provide additional education on this topic. What I can recommend is to research binary communication protocols, not Ajax html JavaScript json programmer-friendly webservice approaches. I'm not certain if you truly understand how quickly the ezb is doing things, including audio, video and servos... This is an effecient binary communication protocol. The communication does not initiate with the ezb. The connect button on ARC is a dead giveaway, and the fact the ezb doesn't know where your ARC instance even is. You do not open tcp ports on the the Windows machine because there's already an established tcp connection.

groundwork research is a good place to start - specifically regarding the servo question.

Most computers have 4 cores now. Even most Atom processors have 4 cores now. It is possible that you have a pc with 2 cores, but if that is the case, there is a technology that was used to make these look like 4 cores at the time.

The OS (I think XP and above but maybe even before them) allowed multiple cores. I know Windows 3.51 supported multiple cores. The OS has the ability to handle multiple cores and it is built into the OS at no additional cost.

The more cores the better within reason. You could go crazy and get a server class machine with 64+ cores. 4 is normally sufficient.

Each control that is currently running is one thread. The thread gets an available core and uses it. If the cores are busy, the OS tries to time slice into a core that is being used. Because each control uses its own thread, it is often times better to use multiple scripts to accomplish something. It is what I have said in other posts and one of the reasons that I code the way that I do. Another benefit is re-usability. A script can call another script and either forget about it or wait for a variable to be set which would tell the initial script that the second script completed. Doing everything in a single script limits ARCs ability to utilize multiple threads. Now, it may be that you want something to run in series instead of parallel. If this is the case putting this in the same script is not an issue, but... it is good practice to break up your scripts for a few reasons.

1. If a portion of a script is going to be used by multiple other scripts then it should be written one time and put in its own script. This allows far less code.
2. Breaking up scripts allows you to test specific things and know that they work. From there you just call that script when you need that function and let it run knowing that it will work.
3. It makes your code much easier to manage and far more readable.
4. Multi-threading.

There are probably more reasons, but off the top of my head, these are the most important reasons for me.
@DJ: I said ARC->EZB not the other way,

my background is c++ and c#, i understand how the analog servo works, the point was more to have more control over the task performed by the firmware.

The time is really a constrain thanks for replying back.
@ptp Hey sorry man, I just answered the question you asked...And thanks for reminding us of how smart you are, I had almost forgot... Cheers.. :)

Thanks @David, that is great info too...

I'm always polite, i try to do Devils advocate, etc etc.
Did i said something wrong to get a sarcastic answer from you ?

I only mention my background because DJ mention something like the ajax, json, html, although i know what they are, i'm not familiar with them, so i mention my background.

Thanks for your motivation, it seams you re happy trashing other people's questions when they are trying to figure out how the things work.

It's my bad there are a lot of SDK code, like for example the Universal bot where i can learn more, so i'm guilt of being lazy and ask the question.
Thanks David, Your a great teacher. I already know some of your answer and guessed some of the rest but your guidance cleared up everything.

As for cores, I do know I only have two in my old Dell. I was wondering if I'm throttling my busy project when many controls are running at once or popping on and off (I do try to have proper sleep commands in them). I notice (I do have the latest version of ARC) when long audio is streaming and something like the AutoPosition control is running that I am getting broken audio sometimes. I thought more cores then two would assist but it could be something else. I'm sending Serial commands through the Uarts at the same time also so I could be also be having Comm flooding going on. Humm, resource management. Can't wait for the new EZB to come out. :)
@Dave... I am going to go out on a limb (hopefully @DJ will back me up here) and say the the soon to be release ezb4.1/2 will/may eliminate most if not all your "lag" issues... Communication is only as fast as the weakest link in the proverbial communication chain so to speak... I know that the ezb4.1/2 is much faster than the current ezb4... Here's egg on my face if it doesn't, though...:)
Here is the danger...
The faster the pc, the easier it is to flood the communication channel. I think the weak link will be the pc when the 4 1/2 comes out especially if using the usb comm board. It is easy to check if your processor is being pegged though through the resource monitor on your computer. If it is at 100% while seeing the issue, it is your processor.
@David... ahh... very good point... Maybe ARC needs a "throttle" control (for fast PC)... LOL