Sorry to hear that... all my ezb's move data blisteringly fast... way faster than the ezb3.... How new is you pc? Maybe it has a crappy wifi adapter?...Sorry I can't offer any more help than that...

This happens to me if I have tooany adc monitors open and actively watching the ports. When I pause the controllers everything speeds back up. My point is that this control uses so much of the computers resources that it bogs the computer down not the ezb. You may not be useing these adc monitors but something in your project is hogging all the computer's resources or choking up the comunacation network between it and ezb. The best way I've found to manage resources is to make sure that if you have scripts that loop that they have small sleep commands in them. This helps to clear up resources. Kinda like stop signs at a busy intersection.

I don't think it's possible for the ezb to change your network gateway address. That must have happened some other way. confused

Similar to Dave's advice, if you are using analog ports (and most of the sensors you listed appear that they do) and not pausing at all between readings this will happen. Even a 50ms pause in your script is enough to give some cycles back to the CPU and keep it humming along fine.

re: the network issue, there is a bug that the Wifi doesn't turn off its DHCP server when you switch to AP mode, so if your router responds slower to DHCP requests than your EZ-B does, the EZ-B will start handing out addresses. The problem is it will hand out the default router correctly, but will give the router IP as the DNS entry, so if your router is set to hand out DNS entries rather than acting as a local DNS server, it can cause devices which boot after the EZ-B behave strangely (and if you are using "static dhcp" they may not get the addresses you expect).

This also causes EZ-B's that boot after the first one to get addresses assigned but he first EZ-B rather than your router, so they may not be the address you expect either, but they will be the lowest available address on your network. (for instance, if your router is 192.168.0.1, first EZ-B will get whatever address you have assigned, or lowest available. So, say you assigned 192.168.0.100 to the EZ-B, but everthing between 192.168.0.2 and 192.168.0.99 is free, the second EZ-B to boot will be 192.168.0.2 regardless of whether you assigned an address in the router or not.

Those using newer Dlink routers, or the new Verizon FiOS Gateway don't see this issue because the DHCP server in the router reacts faster than the EZ-B. TP-Link routers seem particularly slow to respond to DHCP requests, so experience this all the time, and other cheap routers seem to have the problem. I don't have an exhaustive list of ones that work well and ones that don't.

You can see all the ugly details, including network traces that show what is going on here: https://synthiam.com/Community/Questions/7229

I'll be writing up a tutorial for using multiple EZ-Bs on a network, including a few workarounds to this bug soon. Wanted to get it done this week, but I have been under the weather.

DJ has a ticket opened with the WiFi chip vendor, but they have changed owners recently, so I don't know if he has made any progress.

Alan

Thanks a lot everybody, really helpful. Alan, it makes sense indeed if the EZB's DHCP is not stopped under client mode. I hope they'll come up with a firmware correction ASAP because this is not really acceptable to pay so much for less performance, as a result, than what I could do with the V3. I should be able to work around that for now, thanks to your advice.

For the latency I'm not sure to know what to do then, beside using less sensors, which are indispensable to detect obstacles located on different levels or even on the side of the robot so it can run in straight lines at safe distance along walls. This worked so far under V3.

My computer is a 6 core with 16gb memory so I don't think it's a computer's performance issue. Network adapter, maybe, but we're talking about top expensive routers here (I have four routers bridged, one is DD-WRT on netgear AC8350).

The check interval for all my sensors is 500 ms. Is there any other way to have ARC to prioritize digital commands over analog readings?

THanks again, Elfège.

It sounds as if the project could be optimized for wifi communication - which introduces a minor higher latency over bluetooth, even though wifi is higher bandwidth. The higher bandwidth enables more features, such as streaming audio, video and larger packet size for AutoPosition and multi-servo movements from controls. The very uncommon scenario that you are experiencing can easily be resolved with a code/project audit. Normally, the higher latency of wifi over bluetooth during an upgrade migration is very minor and not noticeable unless rare circumstances. Post your project and I will review it for optimization recommendations.

If the question "prioritize digital ports of adc" is asked, then there may be a misunderstanding of how ARC and/or programming works. I won't be able to cover the entire details of computer programming, but i will introduce these two properties...

#1 programs run linear from top to bottom. Each line of your program is executed in a formally fashion - within exception of snippets which are skipped due to GOTOs, IFs, ELSEs, etc.. If the program was meant to read a digital port and analog port, the priority of which one to read can be determined by having one in front of the other. Keep in mind, a program in ARC is each EZ-Script program, which there may be many due to the multi-threaded control model.

#2 ARC uses a multi-threaded control model. There is a tutorial in the learn section regarding controls and what they are. Each control is a behavior for the robot. A camera control is for vision. An Auto Position is for GAIT movements. There are hundreds of controls and plugins using the ARC open architecture. Each control runs in its own thread or process. The communication between controls is done through a channel referred as the ControlCommand(). The ControlCommand() enables controls the ability to "speak" with each other, exposing available features which can be accessed. If two controls are running, each reading a digital port and/or an analog port - the priority of communication activity can be determined by the timing configured to the controls, which run independently. Multi-threading or multi-process means that each control runs separate from each other as isolated programs. Again, the processes/controls can communicate using ControlCommand(). Choosing port priority is based on what timing speed each control is running while communicating with desired ports.

The short answer to summarize the "does ARC prioritize ports" is: Your program decides by which port is read first, and/or which port is read more often, respectively.

As for the DHCP - the manufacturer of the wifi chip used in the EZ-B v4 had communicated with additional detail about the DHCP, which i had not communicated in Alan's thread. The DHCP on the wifi chip is delayed to "wait and see" if there is another dhcp server on the network. This is a feature used for portable networks where there is no dhcp and only a common access-point. Because this wifi chip is optimized for use in robotics, plc, iot and other portable network applications, it is common for these networks to not have dhcp servers. So the wifi IC delays and responds accordingly. Due to the slow processing speed of some older home routers, their dhcp server may respond slower and therefore trigger the dhcp server of the ez-b v4 wifi chip.

This is why ez-robot has been unable to reproduce the experience which alan had introduced in his thread - in both my home and office network. This instance has only arisen less than a handful of times on the forum, and has been resolved with router upgrades.

The DHCP delayed server does not affect communication performance. DHCP is the protocol used to issue IP addresses to devices and computers on a physical layered network. This means a network not separated by routers, such as your home network.

If the DHCP delayed server is responding due to the delayed response of the home network router, report your router model and version here to me with a description of the experience and i will compile a trouble ticket with the vendor for resolution.

Something to note, the wifi ic on the ez-b is being discontinued by the manufacturer, which may mean no further upgrades. Even though there will be plenty of surplus inventory of the wifi chip, ez-robot does not manufacture hardware with discontinued components - so ez-robot is changing the wifi chip for 2016. Due to the modular design of the ez-b v4, the communication board of the ez-b v4 can be swapped out with the new module when it is available - if the issue with delayed dhcp continues to cause issues.

If you want the DHCP completely disabled - and control over the wifi module code directly, you can re-flash the wifi module. All you need is one of these: http://www.ebay.ca/sch/i.html?_from=R40&_sacat=0&_sop=15&_nkw=pickit+3+clone&rt=nc&LH_BIN=1

If you buy one of those, i can create a quick tutorial and give you a new firmware which entirely disables DHCP on the chip. Alan, this applies to you or anyone as well. Unrelated to Alan's dhcp server experience, ez-robot has been thinking about releasing the webserver firmware open-source for customizing web UI and additional custom features. Perhaps this is a good time to do it. Get one of those pickit 3 programmers (the clone ones work great) and i'll get on pushing the wifi code on this website.

Lastly, if you believe the performance is far too unusable - there may be a defect in the manufacturing, which is unlikely but possible. That being said, feel free to Contact Us and send the ez-b v4 directly to our facility in Calgary, Alberta for review and/or repairs/replacement under warranty.

It seems that the problem comes from ARC in fact because if I run diagnostic commands from the web interface while all my ADC ports are on, the EZB receives the commands immediately. Now, I tried to run EZB from four different computers and symptoms are exactly the same : as soon as there are more than 3 ADC ports running, latency can go up to 30 seconds, if not more.

There is definitely something at the level of EZB that seems to not be able to exploit network capabilities properly.

I also configured a test project with only ADC ports and one digital D8 button and here it goes : 5 ADC ports on, very long latency time, as of 3 ADC ports running and below, almost no delay. In all cases, again, commands sent from the web interface are always ok.

Has anyone any idea what could cause that in ARC / windows settings maybe? I run under windows 7 ultimate.

Best,

There are tens of thousands of ez-b v4's out there These experiences are entirely unique and therefore can be resolved. Let's work together to solve the latency issue which you are experiencing. To begin, please submit a diagnostic report: https://synthiam.com/Tutorials/Help.aspx?id=220

Also, please acknowledge that you have read and understand my previous response.

DJ, Great information on the delay function on the WiFi chip. Totally explains the symptoms I have seen (except that it is not a problem with just old or cheap routers. I experience it with a TP-Link Archer C5 and C8, which are very high end modern routers, and the C5 has one dozens of best by awards). However, I will report the issue to TP-Link to see if they can speed up the processing of DHCP requests in their firmware.

I'll probably also take you up on instructions for flashing the chip on my EZ-B's and buy one of those devices since I will probably always be using a router.

Elfege, Post your project to the thread so DJ and a few of us can review to see if there is anything that could be causing your issues with analog port performance. Many of us use all 7 analog ports without issue as long as we are careful not to have no-rest loops.

Alan