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.
I give points to everyone who helped, but Alan had already solved this with someone else correctly, and it was due to his diligence that the problem was initially solved. Also he explored the details of my case in great depth. So I have to give credit to Alan. Thanks Alan
Glad you are back up and running.
Alan
@Zxen, probably a good time to use this opportunity to learn something new about computer software. If you have ever used software, such as Microsoft Word or Excel, there is a save button. The save button will take the current "work/changes" and save to a file.
This file can be loaded again in the future. You asked for a "patch" to disable the battery monitor, saving the document with the settings/configuration is the "patch" that you are requesting.
*Note: Files are also called Documents in some software. In ARC, files are called a "project".
In the case of ARC, it appears the confusion resides in GUI elements and file saving. EZ-Bulder uses standard controls (buttons/labels/checkbox/etc) and follows the Microsoft Windows standard GUI approach. This means checkboxes used to enable/disable features, buttons, menus, etc.. Since you are new to computers, take your time learning the interface and how "clickable" things work. For example, a clickable thing is something on the screen which you can point the mouse cursor at and press the mouse button. A button is a clickable thing, so are checkboxes.
The "battery is low" message will repeat until the battery monitor is disabled. As you have noticed, the battery monitor will also disable i/o to prevent battery damage and burning out servos with under power. An under powered servo/motor from a low battery will burn out because it does not have enough strength to move and will be stuck. It's unusual to realize, but under power and over power are both motor/servo killers.
The battery monitor can be disabled by using the checkbox, specifying the ez-b in-which to disable and entering the new voltage level. You mentioned not understanding what a checkbox was in a previous post, or that it's a new feature for you to use on computers. A checkbox is represented as a square, which will either be filled (checked) or empty (unchecked). You will find checkboxes located throughout the ARC software to enable/disable features.
Once the settings/configuration of your project has been created, save it to a file by giving it a filename. This is done using the File->Save button. This is a similar approach to Microsoft Word or Excel. When you load ARC again in the future, use the File->Open to reload the project which will include the settings/configuration, including the battery monitor settings.
Lastly, there was mention that you opened a JD project for "testing". It's no surprise that all robots are physically different. Loading a project that is not for your robot configuration, or for an empty ez-b with no peripherals, is not recommended. A similar comparison would be testing your microwave by putting the Television Remote Control inside it. Just because the item fits/loads, doesn't mean it's the right thing to do. Loading JD's project not in a JD will result in unpredictable behavior. Loading any robot project for a non-robot will result in the same unpredictable behavior
Take your time and be patient while learning a new technology. You'll get there!
So I take it you'll take my refinement requests on board then, DJ? Like I said, whichever microcontroller I use for my company after my prototype is complete, I will need to buy HUNDREDS of them. Please delete your hate speech. I just did over $3000 R&D work for you without demanding a refund.
@Zxen,
Drop me an email (my address is in my profile). Want to discuss something out of the public eye and we don't have private messaging on this forum (yet).
Alan