@Purple, Something has changed as DJ has stated. Others dont see the issue that you are seeing from an actual project perspective. DJ has stated that the Benchmark tool, with the changes to ARC for the new products that are coming out doesn't pause between attempts to access the Analog ports (or really any others) anymore. This is because the new product can handle faster speeds. This will flood your connection and cause issues with the current product. Because of this, what you used to do to gage performance won't work well with this board at this time. The benchmark tool is not a normal function, and thus is irrelevant to your project. If your project is showing slowness, and nobody else is having an issue with slowness, then logically speaking, your project probably has an issue. If you post it and everything looks good with it, then someone will be able to say "yea, I am having the same issue here" or "Nope, no issue here". That will help to determine where the issue is.

I dont think that anyone is saying "Lets figure out what you are doing wrong". I think that people are saying, "Unless I see what you are doing, I cant really help out". Everyone here has tried to be as helpful as possible, but until we can see what you are seeing, it is really hard to help. As stated, the Benchmark tool isnt a good method of determining what is happening because with the improvements in performance on the ARC software that have been put in place (this is a good thing), the bottleneck is now somewhere else in the chain of things that happen to make the robot work. You can see the bottleneck with the Benchmark tool, but that doesn't mean that in a real world scenario this should exist.

If you have seen this issue in the past (which nobody is doubting) then you should have an existing project that demonstrated this issue in a real world scenario. I think everyone wants to see that so that it can be determined where the issue is.

Not at all @purple - there are 263 ARC software releases with fixes inspired from user experience. Your experience has inspired an update today, as well.

The process to identify an issue starts with reviewing the project. Without a project to review, there is no information for me to see what scenario is causing the experience. Once you provide a project that crashes or locks up, it will be easy for me to fix

In this thread, we have identified that the performance enhancements of the benchmark utility flood the communication channel at a high sample count. This has resulted in an ARC update.

Take your time with an Example Project that demonstrates the software lockup - when you come across it, let me know, i'm always here to help.

I have just put up a project to the cloud. It is called 20151219 pausing test. Just notice the changes with and without the Connection Diagnostics running. This is on a bare board.

awesome, thanks!

First, that project has the debug control added, which is incredibly resource hungry and debugs every command sent to and from the ez-b in the gui thread. The plugin should not be used for testing - as it's a connection plugin only, hence the title. The title and description of that plugin in no way leads itself to be used for performance testing. Please do not use the connection plugin when not being used to debug connection failures. Due to this incorrect use of the connection debug plugin, i will update the description so others do not confuse the name of the plugin with a reason to use it for any other purpose.

Here you go - here's the fix for your example project. I added educational notes in the project. Hopefully this will contribute to your programming learning experience

Your new file: PurpleFixed.EZB

Let me know if you have additional questions.

Updated the connection diagnostic plugin with a description that includes the warning about why not to use it. Even though it's name and description does imply what it is - let me know if there are other plugins which may cause confusion and be used incorrectly as well. Thanks!

Here's a video demonstrating to avoid confusion of how the Pause On and Pause Off work... Let me know if you have any questions!

@DJ You are the one that is confused.

What else can i do for you? Let me know and we'll get you up and running!

Go back and run my project. Take note of the update speed of the graphs. Then remove the Connection Diagnostic, now note the speed of the graphs again. Now put the Connection Diagnostics back in and look at the update speed of the graphs. I am using the Connection Diagnostics to show that with it added to the project the update speed increases by 5 times. This corrolates to the read 300 adcs. This also contradicts your flooding the communication link theory.

I'll go take a look! Be right back!

Nothing is theory when it comes to logic :). The data channel is indeed flooding, which is causing something interesting to happen. On my slower PC, the data is slower with connection debugging running, with different experience on my faster PC.

It appears the faster PC's are shoveling data too quickly at the ez-b v4 and she's having trouble keeping up, by flooding the data channel. It seems that the slight delay of the connection diagnostic tool is giving the ez-b v4 a chance to catch up.

Perhaps the solution is if i add a tweak-able delay parameter. Let me debug a bit more this evening and see what i come up with.

Stay tuned!

@DJ, remember I'm not down. Everything works fine. Happy holidays

Give this build a shot: http://www.ez-robot.com/Community/Forum/Thread?threadId=8766

I'm not fully sure how to handle this scenario with the new Comm being released next month... Because this setting dramatically decreased performance capabilities of the ez-b v4.1/2, when people start to get it.

I'll think of something in the meantime - let me know how this works for you. What ever you do, don't run the Connection Diagnostic plugin with this setting - or the performance will be severely affected. Start with a value of 1 and run the benchmark. On my fastest PC, the value of 1 seems to great.

On my main PC the value 8 works the best.... At an 8 micro second delay the Benchmark for analog reads shoots way up from 5 reads/second (0 microsecond delay) to 70 reads/second at 8 mirco second delay

I wonder if anyone looks at the graphs. I mean really look at the graphs. Because if you take a minute and look at them you could see that they, run then pause, run then pause, run then pause. You could say, well that's because of this or that etc. etc. etc. But I'm not buying it, I won't even rent it. Because I never had any analog input read issues with the v3 board over bluetooth. I still have a v3 board but that has the issues too, I say it's a problem in the code. I wish I would have saved older versions of ARC. Then I could go back to a working version. I would like to say it is usable but annoying to have graphs pausing, but I am starting to think that maybe the ez software has become too complex to be fixed.

The graphs will pause while waiting for network communication if there are wifi issues. I experience no pausing, except for the 100ms delay between requests.

Perhaps you can benefit from changing the ezb v4 wifi channel? Run a wifi scan to see what channels are free in your area?

Also, how is the ezb connected in the robot? Is it shielded by any metals? How far are you from the router or laptop? Are you connecting adhoc or client mode?

There are plenty of wifi related questions - because that is how wifi works and it does have its own inherit delays which are out of ezrobot's domain.

The ezb v4 now has the option to throttle delays to prevent flooding to increase throughput. Can you verify the benchmark utility has increased throughout?

@DJ - explain how the same problem appears on my v3 bluetooth connection.

Bluetooth is also a wireless signal. Both communication methods use rf (radio frequency) to communicate.

If the issue that you are experiencing is a short occasional pause while reading data, then consider checking for wifi interference as mentioned and how the controller is mounted in the robot.

Also consider applications running on the PC which may affect performance.

Only one command can be sent at a time over a single connection - which is how the ezb works. It's faster that way, than opening a new connection for each request. Sharing the connection requires less back and forth conversation and resources in the form of sockets on each endpoint.

As all controls and commands are sharing the connection, they stand in line waiting for the next response. So, you can imagine what happens when one request is delayed, the rest in the queue have to wait their turn.

Anything else I can help you with?

No I'm all set.

Excellent!