elfege
USA
Asked
— Edited
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 = ""
:loop1
$last = "loop1"
left(200, 0)
sleep(100)
print($last)
goto($last)
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. 
By the way, this is the proper way to post code snippets. Anyway your code would not cause a stack overflow anyway because it wouldn't even run due to typos...
Thanks to all for the answers. I am new to EZ-Script. Have only had my EZ-Bv4 for less than a week. But have my R2D2 already running around the garage.
@rz90208 Well then welcome... Nice Christening LOL... OK What? And you never posted a video or pictures? Shame on you... seriously we wanna' see...
Is it an Astomech R2D2? There are a couple on here that rock....
Nice! that's awesome! I have an r2d2 collecting dust that i really need to get my act together on someday.
My career background is in tech security, as well as hardware in robotics. When building ez-robot from the ground up, i implemented a bunch of work-arounds for struggles that programmers have experienced. One of those, ironically to this topic, are stack overflows
The concept of EZ-Script and ARC is to run each control as a separate process. Think of these controls as totally separate programs. Each control can only run once, meaning it has only one thread. A single control will never have two threads to perform things twice, that would require to controls instead. The EZ-Script runtime works the same way, each instance can run only once.
Say you are using EZ-Script in the WiiMote control and the script is applied to a button. If the button script has a...
then the code will run for ever... until it's told to run again. In which case the script will be told to stop, and start again. This approach only applies to "Behind the scene" scripts, such as those in the camera control or wiimote, or myo, or etc etc etc...
The difference between the behind the scene scripts and a traditional EZ-Script control is just that. The EZ-Script control will only run once, and if it's told to run again while running, a message will be displayed in its console stating that the script is already running.
Take a look at the Examples folder that is included in ARC. There's a few Procedure example projects that demonstrate it.
@DJ sorry slightly off topic... I am curious about something and forgive my ignorance showing here. We all know arduinos are not multitasking controllers... sure they have interrupts... yada, yada, yada, but really they basically perform one instruction at a time... With ez robots approach where exactly does the mutli tasking/threading take place? In ARC or on the ezb4 itself? Or a combination of both? Again, sorry if this is an obvious answer...
ARC let's the multi threading take place on the pc.
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...
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...
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...
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....