Thats a good question. No to side track, but always wondered about how many scripts could be run before things kinda run outta steam. My project only has about 6 or 7 scripts and it seems to seem to cause disconnects alot of times,

I think you are going to need to do something more like this...

if($last = "loop1")
   goto loop1
else
...
end if

forgive me if it isn't working code. I haven't been in the scripting world for quite a while and it may not be the exact syntax, but you get the idea.

Not that this next part is to the first question, but hopefully answers the other concern mentioned... Also, I try to write code so that one script does one thing and is called by other scripts when that function is needed. This allows you to call the same script from multiple other scripts (reusable) when that function needs to be performed. Because of this, I have projects with over 100 scripts in them without seeing any performance issues. Multiple of these scripts are running at the same time in their own threads without seeing performance issues.

That isn't possible because the compiler preprocesses the opcodes for things like goto, Return, if, elseif, if, etc...

A compiler is a process that runs on code to convert it into a structured logical path and logical elements which the cpu or virtual processor understands. Without this process, the "scripting" language would have to evaluate the whole script for each line of execution. That would cause performance issues in the hundreds of times less.

Ezscript and all languages that compile to opcodes are effecient for that reason. Without an opcodes preprocesser, I doubt your cpu would be able to run more than 3 or 4 scripts at once.

@RoboHappy I am going to say the way you are coding or your power source is what is causing your disconnects... As David mentioned, proper or better scripting techniques would probably eliminate your problem... I run multiple scripts all the time with zero performance degradation and certainly no disconnects...

As CochranRobotics mentioned, offhand the only way I can think of would be to use a variable to run through an IF-ElseIF combination. For example:

$lastLoop = ""

:loop1
  $last = "loop1"
  left(200, 0)
  sleep(100)  
  print($last)

f($last ="loop1")
  goto(loop1)   
elseif($last ="loop2")
  goto(Loop2)
         |
        etc.
         |
endif

The closest there is to automatically returning from where you left off is to use a CommandControl statement. To eliminate redundancy you could set a variable to a portion of a script and use an If-Elseif statement to go to that portion of the script upon arrival, after using a CommandControl. For example:

$Function ="FunctioOne"
CC("MainScriptManager",ScriptStartWait,"MainScript")

  #And at MainScript would be:

if($Function ="FunctionOne")
  Goto(FunctionOne)
elseif( $Function ="FunctionTwo")
  Goto(FunctionTwo)
               etc.
endif

:FunctionOne
  #Do Function One stuff
  Goto(TheExit)

:FunctionTwo
  #Do Function Two stuff
  Goto(TheExit)

           etc,
   
  :TheExit

If you're interested, I've developed this idea (possibly to a ridiculous degree) to include a form of pseudo parameter passing and variable localization. I have uploaded a project called HTML Reader which uses these principles as part of a project to read certain portions of web pages.

@Richard R... Yes I would have to agree, thats what I figured it be as well. Since I am still learning much about Ezb script writing, I have ways to go ( And I thought my Basic Stamp was hard). Im trying to run the Speech req,rgb animator,2 drive wheels,use 5 ultrasonic sensors,1 IR sensor, the camera,the Wii controller, 8 servos (for arms) so far. I dont know if thats alot or pretty normal really.

RoboHappy, post your project - everything that you're doing is fine. I suspect the number of IR sensors and Ultrasonic sensors is the issue with disconnects.

@RoboHappy One of the things I have found that will cause a disconnect is recursive calls to scripts. That is to say, scripts which call other scripts in such a way that a script ends up effectively calling itself. It usually takes a few seconds for it to happen as the call stack builds up to an overflow condition. They can also be tricky to track down since they can take unexpected routes. Also, it doesn't happen every time since the program flow can be different under different conditions.

For example, using CommandControl statements, Script A calls Script B, which, in turn, calls Script C. But Script C calls Script A, which calls B again, which calls C, and so on and on until the system runs out of memory which causes the disconnect. I'm not sure why it disconnects, but that seems to be the result.

I would suspect that you are flooding the communications channel by querying the sensors to rapidly. Increase the sleep command and see if that helps you out.

@wbs, that situation is not possible with ARC. If a script is already running, it will not run again. In a threaded environment, only one instance of a thread can run at once, because it is only a single instance. A thread is a single instance. A thread is not more than one thing, it is only one thing. Each control/script runs in a separate thread. Meaning, it is only one. One thing can not run more than once. You can only have one instance of one thing.

ARC will never crash from that scenario, nor will the communication drop due to that scenario.

Instead, the two previous versions of the EZ-B v4.x/0 and EZ-B v4.x/1 will drop communication if the connection is flooded. This is due to processor limitations of the wifi module and tcp stack buffer size. The most recent EZ-B v4.x/2 (shipping in April) will never drop communication channel because it has enough memory for a much larger buffer and significantly faster processing speed.

With the EZ-B v4.x/2, you can run a loop of getting and setting ports without a sleep(). This, of course, is not to provide an excuse for poor programming structure of excluding sleep()s even with the EZ-B v4.x/2.

However, the current EZ-B v4.x/0 and EZ-B v4.x/1 will drop the connection if too much data is received for the reason stated above.

There is a setting in the Connection Control config menu for data flood prevention for advanced users. There is a question mark which you can hover your cursor over for additional information on how to use it. It varies per CPU and Windows Installation. This data flood prevention value is ignored when used on an EZ-B v4.x/2

PS, look in the Examples folder that is included with ARC for a project called Procedural 4 (Threading). This will give you an example of how threading works.

Quote:

With the EZ-B v4.x/2, you can run a loop of getting and setting ports without a sleep()

Hi Guys, Thank you for any advice you can offer.Have uploaded my project file. It may look like a jumbled mess,hence needing advice on proper program organizing as well. Its a start at least. eyeroll

@DJ Are you saying that it is impossible to get a stack overflow? I have been concerned about this.

:DomeLimit If (GetADC(adc2) >2.5 and GetADC(adc3) <2 and GetADC(adc1)<2) Move(D2,"stop") ... goto(DomeLimit)

This will not eventually cause a stack overflow?

@rz90208 You can also pour sugar in your gas tank to see if you can "stuff up" your engine... What's your point? There is always a way to screw something up.. @DJ was just lamenting about the attributes of the new EZB4.1/2. He didn't say it was bullet proof

Correct - that will not cause a stack over flow. For example, this will not cause a stack overflow - ever ever ever ever ever ever ever ever ever (rinse, repeat)

:start

if (1 == 1)
goto(start)
endif

The only issue that would happen from the example you provided was covered in detail in my previous post regarding communication flooding - which is not possible to happen using the EZ-B v4.x/2, available in April. I recommend re-reading my previous post for clarification.

It is impossible to create a stack overflow using the EZ-Script compiler and runtime. This is because the executor has a circular buffer on the stack, which is quite large - it's to the size that it doesn't make sense that any EZ-Script would ever need to recover with "returns" from a depth of over a million levels - or have a million conditions...

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...

inomeLimit
If (GetADC(adc2) >2.5 and GetADC(adc3) <2 and GetADC(adc1)<2)
Move(D2,"stop") 
...
goto(DomeLimit)

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...

:loop
 #do something
goto(loop)

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...

Quote:

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...

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

@DJ:

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) ?

Quote:

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,

Quote:

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?)

Quote:

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

Alan

@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

@alan:

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: https://synthiam.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.

Dave,

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...

@Richard

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

A turbo button ? lol

Good points and advice as usual guys.