
Purple
USA
Asked
— Edited
When I do a benchmark test of the Read 300 ADC I get a result of 5 reads per second. I know it use to be around 65. I thought it was because of the "Limited" WiFi message, but its not. I have changed to a different board and changed computers. Anyone know what I can try now? Thank you
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.
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.
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.
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!
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.
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?
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?