I cant check the project since im not home but check your scripts arent bogging down the pc too much. Add in or extend sleeps. Rwduce the number of adc checks etc. All of this will bog down the pc and create lag.

Ill check it out when im home.

Thanks Rich, I have a couple of small scripts in the project and have used them many times with no issues. I was not even using the scripts when the lag started. This has happened to me before a few times. It's like some buffer fills up or something and when it happens I have tried delays added to scripts, then I would start removing ADC graphs and readouts one at a time and nothing effects the lag at all. Once it appears, nothing that I have tried can get rid of it. It ends up that I have to scrap the whole project and start over. I use to think it was my old vista computer running XP, so I went and bought a brand new computer with built in Bluetooth running windows 8.1. and this little lag still creeps into my projects. I know that its been stated that you can't have to many ADC graphs, Get ADCs, etc. but how can I plan a project out if I do not have any heads up of what or how much, I can and cannot have in the project. I really do not think that I am asking for too much from the ARC program or v3 boards that I have. Remember there is a time when the project is working then after a while it starts lagging. I hope you can see something. Thank you

Could it be a power issue? I always use batteries and when they start to get low, thing start to get slow. Make sure you have a good source of steady, stable power. That would be the only thing I can think of, from my experiences, that would cause a delay.

Also, Using graphs, or anything like that, that requires on the fly visual rendering, has the potential to bog down a PC. Even a brand new PC unless it's one of those souped up gaming PCs is going to have issues with rendering lots of things at once. To find out how much is too much is going to be a trial and error process with your set up. Everyone has a different set up in regards to the specs of the PC they use for their projects so no one can put a definite number on that for anyone..

But, I'm still leaning towards a power issue. What are you using for power?

Where is the project file? I checked the cloud but there are 2, both of which are quite old and both work OK without any issues (and no reason for any lag other than the 2000ms sleep in the script)

@Rich, You should see the project now. I forgot to mark it public. I have just backed up to my previous days version and it works fine. So I am ok for now, but I am starting to believe that it may be related to the ADC meter that I added. Everything was working as expected until I did something and I don't know what that is. Also if you want to see that lag you can watch the slider bars on the PWMS not following the way the script has them being executed. You can also put leds on d1 and d2 and visually observe how the lag affects the script. Once again I am still moving forward with an day earlier version for now. But it would be nice to identify what it is I am running up against. Thank you

It's more than likely to do with the ADC. You have 6 ADC meters from the looks of it, these can cause a heavy load on the PC.

The V3 board runs on bluetooth and therefore the bandwidth of the comms between the EZ-B and the PC is limited. If you are checking the EZ-B ADC ports 6 times every 100ms it's going to place a demand on the comms which will slow down the responsiveness of ARC (it'll wait there until it gets the info it's asked for). The comms is a huge bottleneck with the V3.

Try reducing the time the ADC graphs check the ports to see if that helps at all.

The V4 has faster comms and even on my V4 the benchmark shows I get 8.85 commands per second when reading ADC which was much better than my V3 benchmark. You are requesting 4 every 100ms and 2 every 500ms, that totals 44 commands per second which is 5 times what my V4 can read.

Run a benchmark (control in Project, Add, General) and see what your benchmark for reading ADC is, then adjust the times to be below that.

I cant have any ADC grafts or meters running or my project bogs down and scripts run intermittently. I have to check the "Pause" box. I've also experienced sound lock up on my V4 EZB when a loop is running while monitoring an ADC port. I did find relief when I added a short Sleep() command in the loop but it didn't completely fix it.

I know it doesn't help but it does validate what your saying. Sorry.

@Antron007 Good suggestion, I have a wall type supply but have not even thought of its output in a long time. I checked it it is 12.3 Vdc. so I think were good there. @ Rich I see you are getting 8 ADC reads per second. I get about 25 on my new computer. On my old vista computer running XP I got 17 per second. I was surprised to see that much of a drop in v4s Get ADC execution time, maybe it has to do with the higher resolution. I know that I am pushing the v3 to areas that most don't go to, as far as adc requests/graphs and speed of the script loop. My intent is to rewrite and move this portion of my project to one of the "other" boards for speed after I develop it in the ARC enviornment, which is working great for the development part. Then I can have the other board handle the high speed data collection and then have the EZb v3 or my v4 (in July I hope) handle the major portion of the program. Think of a robot that has to do balance or a helicopter etc., you would need to get position data and execute commands very fast, I think faster than the EZbs can go. I hope I am thinking correctly on this plan of mine, I would welcome any input/ideas on this. Thanks again

Even if you were to write a program directly onto a microcontroller, you will need to identify how to distribute resources for performance. The same practice needs to be applied to EZ-Robot. I have had consideration for adding an auto-throttle (Similar to QOS on a router) for the communication module. At one time, the EZ-B v3 had a built-in throttle but it created problems with people who "knew what they were doing and didn't want the communication throttled"

So long story short, EZ-Robot is also about learning and education with a fun result of having an amazing robot. Managing your resources part of the learning fun :D

As dave mentioned, slowing down the sample rate of a GET command is ideal for sharing resources. In script, I recommend SLEEP() within a loop when sampling ADC data.

If you are using the ADC Graphs, they are pretty but very resource hungry. Be careful how many you use, and how you are using them.

I was sure the V3 is slower than the V4, I'll have to do another benchmark on my V3 at some point.

Either way, you are still requesting ADC values 44 times per second which is higher than your benchmark of 25 per second. Also, as others have mentioned, the graphs are resource hungry.

Personally I write scripts, loop them with a sleep of 1000ms or so (depending on what's being monitored) and have the script Print() the results. This way the script control will continue to update with the ADC value but wont be anywhere near as resource hungry. Check my Battery Monitor Example for example scripts that check the ADC and Print() the results.

OK, I get it I will be more careful about too many adc requests. Luckily I can adjust my project and not request too much. @ DJ Can you comment on why the v4 gets 8 adcs per second and the v3 gets about 25 ?, my guess it's because of the higher resolution, just curious.

It may be my network, I have a lot of traffic on my network and on the PC I used to run the benchmark

Always run your own benchmarks as they will all be different, especially the V4.

The first thing I noticed with my project when I switched over to the V4 was that ADC requests that worked just fine with the v3 was stalling execution of other commands. Mostly servo movement and sound lock up. Once I stopped the offending ADC script everything would start working again. I thought it may be due to WiFi but I really had no clue. The sleep commands helped a lot but my scripts still need work. I also am wondering what changed.

Thanks all for the help.