Zxen
Resolved by thetechguru!
Every time I move a servo through WiFi the ezb v4 makes a chime like its starting up but its really disconnecting.
I tightened the female connectors (I dont like the dean prongs - the base doubles the size of the unit for no reason).
I thought this might be due to the 6V20A power supply I had begun using instead of 7.5V48A I was using previously (which fried about 12 servos). I remembered some kind of battery failsafe minimum voltage shutdown setting (which I turned off after clicking the settings cog button next to 'Connect/Disconnect' in ARC software. I had already switched it off so I wasn't sure if it was my faulty power supply, a faulty power supply to ezb wiring issue, the low voltage, bad wifi, a bad servo. There needs to be a troubleshooting guide built into ARC when things go wrong I think.
My new power supply has a 12v/6v switch. I had set it to 6v so as not to fry my little Hitec mini servos (225mg). I also had a torxis monster 1600 servo but using a different power supply. Was there a conflict between the servos? Was Channel D1 faulty? I unplugged my little servo which used ezb power and the problem went away - the torxis servo on it's own power supply worked well and a wifi cutout wasn't triggered. The moment I plugged the mini servo back in and sent it a command the ezb shut down and up and down again. Problems.
Now I'm back on my 7.5V power supply (with everything working until this servo fries as well) but I want to decrease to 6V. Is 6V too low? Or is it my power supply thats to blame? Or something else? Thanks
EDIT: I just plugged in a THIRD power supply, this time a 12V with a 6V downer module. Running the 12V to the Torxis and the 6V to the EZB and connected servos. Tested lots of servos. All caused the microcontroller to malfunction. Pissed off that the EZB was probably broken at this point, I had one final look at the failsafe voltage settings, hidden away (a clue that the programmers are to blame - not me) where I find that its not the programmers' fault after all - the failsafe override voltage shutdown thing is still unchecked and greyed out, just as I left it. So that couldn't have been the issue. But knowing that anyone who puts the main settings for the ezb in a tiny button like that must have rocks in his head, I wonder if I need to turn the device off for thirty seconds while holding spacebar, return key, alt key, ctrl key, Q, W, L and shift for 500 milliseconds before hitting the tilda key and doing a backflip, I switch the failsafe voltage on again and the box will stop telling me the batteries are low, which she'd suddenly decided to start doing. So I go in and change these settings to 5 in each box while keeping them switched on, and the woman stopped yapping. Thank God for that. It only took me around $500 worth of labour and three years reduction in lifespan due to the stress of figuring out where the programmer's head was at when he was inhaling pure diesel fumes. Problem solved until another crazy software setting gets in my way... I really hope it gets easier after I learn that a square hole in the ceiling is a toilet in this labyrinth.
Thank you, I will try this before seeing if a firewall has suddenly appeared since this morning (there is no camera attached or any servos and the original power supply no longer works either):
Instead of connecting with ARC, go back to the EZ-B web page (open a browser and connect to 192.168.1.1), and go to the diagnostic page. Try to send tones and move a servo from there and see if it resets its connection.
The address you gave above in my browser takes me to the firmware of my modem. I'll try to find the page you're referring to...
I see, I need Windows to at least be connected to the device before that address works, then I click the Chrome icon next to the Connect button in ARC...
Sound 1 not responding. Attempted a reboot but now its complaining that the page is not correct. Refreshing...No reaction to the refresh button. After several attempts, I need to open up my robot and pull the cord again...start up chime, blue flashes...
192.168.1.1 Diagnostics tab. Sound 1 works. I am using a 7.5V46A power supply. Blue LED still flashing. All sounds work. It could not respond when RED LED was present and required a replug. All ports Servos 90 degrees resulted in a twitch on my 9380TH servo, rated for up to 8V or so.
I will now attempt to run 6V33A power and do the same again...remaining connected...Sound 1 works fine as do all sounds. All Ports Servos 90 Degrees resulted in same twitch as 7.5V power supply. Absolutely zero errors. And yes, I'm handling unsealed, exposed 240V wires as I use a drill to swap cables from one power source to the next. I think the electrocution warning should be louder than the battery explosion warning as a lot of people need to run 24 servos for their robots and need high level deadly current to achieve it. See? The argument has no merit. 6V is the most common hobby servo compatible power level. Warnings and Sirens are crazy when you're dealing with robotics. It's like having the horn permanently pressed down on the front of a car so that people know a deadly machine is rolling towards them at all times.
So the diagnostics all succeeded at both 7.5V and 6V. The firewire guess is pretty farfetched unless some kind of Windows Firewall function was on a timer.
Also I updated ARC a few minutes ago. After the successful diagnostics test I ran ARC only to see the automated shutdown and 'my battery is low' requiring a replug. I have changed the limits all to 3V and unchecked them all and saved. I'll reboot the EZB now. Done. Clicking 'Connect'. Instant override. All my changes have been deleted at the moment of connection and I see its all set back to a 7v limit again
Settings page is broken. When connecting through ARC the 3V limit can be enforced with some trickery but the EZB RED LED lights up anyway and is instantly disconnected - this time not for low batteries perhaps. The debug reasons are pasted in my previous debug code above.
Its 3am. I gotta sleep. I'll try to find a needle and stick it in the reset hole for ten seconds or something when I wake up. Thanks for your patience
OK, so when connecting to the EZ-B over port 80, functions that require the EZ-B chip and not just the WiFi to be active (tones and servo movements) work. When connecting over port 24, you get an immediate disconnection.
What Anti-virus/firewall software to you run? Just Microsoft, or a 3rd party? Did the 3rd party get an automatic update today? The symptoms you are seeing are indicative of something interfering with the communication between the EZ-B and ARC on port 24.
One other thought, and it is a dumb one since this worked before, so excuse me, but the RALink problem with Compaq's and HP's had a very similar symptom. The solution there was to put the EZ-B on the network in client mode rather than running AP mode. Might be something to try just to see if it will maintain a connection if in client mode, but I am not sure where to go long term if that does work.
I would run the diagnostic report and submit it to EZ-Robot. I could be missing something that they would see.
Last idea, and again fairly unlikely, but since everything seems to indicate the EZ-B itself is working properly is that maybe something in the ARC install has become corrupt. You could try to uninstall, reboot and re-install (often re-installing .NET 4.5 can also resolve issues, but they are usually more obvious, like ARC not running at all).
Need to disagree with you here. The vast majority of EZ-B users buy LiPo batteries and EZ-B HD servos that run on 7.4 volts from EZ-Robot. A very large number of those users are new to the hobby and have no previous experience with servos, robots, high amp LiPos, etc... Protecting beginner users from damaging their batteries or even their property when the LiPo explodes is more important that hand holding advanced hobbyists who are expected to be able to read the instructions and disable the alarm, direct wire power to their servos, etc....Alan
Again, we were posting at the same time.
I think I see one part of confusion.
There are two places where the battery alarm exists.
In the EZ-B's web page, you can disable the alarm. This is for when the EZ-B is powered up and before connected to ARC, and this will last between reboots, but not through a factory reset.
In ARC (the instructions I gave above in the connection object settings). This over-rides the Web Page setting and takes effect when a connection is made. It is ARC Project specific, so once you make the change, you need to save your project, and always connect with that project, not a freshly opened copy of ARC, which will be set to default, not your custom settings.
Personally, rather than setting the voltage to 3 volts, I would disable the alarm completely as I described several posts up.
Have a good rest and come at it fresh tomorrow. If I am not around to help, someone will be....
Alan
I think @Zxen is doing everything right, he just loaded up a project with I2C communication in it without having an I2C device. This will cause a lock up scenario (Red LED stays lit). He'll either have to plug in a set of RGB LED eyes into his project or remove the RGB LED eyes control from his JD project.
doh... I totally missed that. He did say he loaded the JD project for testing.
Alan
Thanks for all your help, but you appear to have already solved this problem before: https://synthiam.com/Community/Questions/9066&page=6
I could not press the reset button at all. It did nothing. So I unscrewed the case and squeezed the two parts together. Looked like nothing happened, but somehow I fixed the reset button, and probably some kind of internal connection.
As you may have read, the battery issue was not the only problem. It would always disconnect for some reason or another. The problem was within the unit itself. No amount of setting tweaks could have helped at all. I tried connecting as a Client to bypass the connection errors and the light continued flashing green instead of remaining steady, so I looked up flashing green on the forum and found your old solution.
Thanks for your kindness. It appears fixed, and even if its now intermittent (I hope not), at least I know the source of the problem. The interior has a professional, solid build, so I was surprised to see that squeezing the two halves together had any effect. I recommend everyone test their reset button as the first course of action for any major erratic behaviour, especially in cases when it worked earlier that day. It must have been bumped by a robot arm and dislodged by a micron.
I would still like to see a patch to ensure I don't need to turn off alarms every time I use ARC - my servos are going to need to run at 6v, and this should not be made difficult. I hope this is changed in the next update, along with some much needed streamlining of the settings. Thanks again for your help.