It sounds like you've been very thorough on the software side, and it's frustrating when the changes don't resolve the disconnects. Moving to hardware troubleshooting seems like the logical next step. Here are some suggestions as you work through the hardware side:

• Powered USB Hub:
  Adding a powered USB hub between your computer and the USB-to-Serial converters can help ensure that the EZ-B controllers receive a stable power supply. This can often eliminate issues caused by brownouts or insufficient power available on integrated ports.

• Cable Quality and Routing:
  Once you have physical access, check the quality of the USB-to-Serial converter cables. Make sure they’re securely connected and that there isn’t undue stress or cable damage. Also, verify that the cables aren’t running too close to power lines or other sources of electromagnetic interference (EMF). Even though your ADC polling wasn’t the culprit, EMF from nearby power cables remains a possibility.

• Power Distribution Within the Robot:
  Since the computer and the USB-to-Serial converters are located inside the robot, consider whether any internal power distribution issues might be causing voltage drops or interference. A powered USB hub is a good first test, but also check if there are any loose connections or signs of wear on the cables inside.

• Re-Test After Changes:
  Once you’ve integrated a powered hub or improved your cable management, monitor the connection again using the Connection Diagnostic Skill. This will give you feedback on whether the changes have stabilized the connection.

I understand it can be a hassle to open up your robot again, but these steps might ultimately save you time and frustration later on. Let me know how it goes once you have a chance to test the hardware changes. If you run into more issues or have additional questions, feel free to keep me posted!

@Athena

I don't know if this should be in it's own thread. However this is related to this one.

until I get my disconnect issue figured out I want to have ARC check my connections every so often and reconnect any that become disconnected.

Here's a script I wrote in JavaScript that does this. Could you refine it if needed and make it into a loop that will run every minute to recheck?

//Check that EZB Connection "0" is connected
var conn_0 = EZB.isConnected(0);
if (conn_0 == true){
 print( "EZB 0 is connected: " + conn_0)
}else {
print( "EZB 0 is connected: " + conn_0);
ControlCommand("Connection", "Connect0"); //Torso EZB through COM Port 4
sleep(500)
ControlCommand("Soundboard v4", "Track_77"); //Say "Loading"
sleep(1250);
ControlCommand("Numbers", "Track_0"); //Say number "Zero"

 }
 
sleep(200);

//Check that EZB Connection "1" is connected
var conn_1 = EZB.isConnected(1);
if (conn_1 == true){
 print( "EZB 1 is connected: " + conn_1);

}else{
 print( "EZB 1 is connected: " + conn_1);
 ControlCommand("Connection", "Connect1"); //Legs EZB through COM Port 3
 ControlCommand("Soundboard v4", "Track_77"); //Say "Loading"
sleep(1250);
 ControlCommand("Numbers", "Track_1"); //Say number "One"
  
}

sleep(200)

//Check that EZB Connection "2" is connected and continue script. If not will be Id'ed in next statment
var conn_2 = EZB.isConnected(2);
if (conn_2 == true){
 print( "EZB 2 is connected: " + conn_2);
} else {
 print( "EZB 2 is NOT connected: " + conn_2);
 ControlCommand("Connection", "Connect2"); //Arms EZB - Com 5
 ControlCommand("Soundboard v4", "Track_77"); //Say "Loading"
 sleep(1250)
 ControlCommand("Numbers", "Track_2"); //Say number "2"

}

Below is a refined version that wraps your checks in an infinite loop so that every minute (60,000 ms) ARC will check each of the three connections and re-establish them if needed.

while (true) {
    // Check EZB Connection 0 (Torso EZB through COM Port 4)
    var conn_0 = EZB.isConnected(0);
    if (conn_0 === true) {
        print("EZB 0 is connected: " + conn_0);
    } else {
        print("EZB 0 is NOT connected: " + conn_0);
        ControlCommand(Connection, Connect0);
        sleep(500);
        ControlCommand(Soundboard v4, Track_77); // Say "Loading"
        sleep(1250);
        ControlCommand(Numbers, Track_0); // Say number Zero
    }
    sleep(200);

    // Check EZB Connection 1 (Legs EZB through COM Port 3)
    var conn_1 = EZB.isConnected(1);
    if (conn_1 === true) {
        print("EZB 1 is connected: " + conn_1);
    } else {
        print("EZB 1 is NOT connected: " + conn_1);
        ControlCommand(Connection, Connect1);
        ControlCommand(Soundboard v4, Track_77); // Say "Loading"
        sleep(1250);
        ControlCommand(Numbers, Track_1); // Say number One
    }
    sleep(200);

    // Check EZB Connection 2 (Arms EZB - COM Port 5)
    var conn_2 = EZB.isConnected(2);
    if (conn_2 === true) {
        print("EZB 2 is connected: " + conn_2);
    } else {
        print("EZB 2 is NOT connected: " + conn_2);
        ControlCommand(Connection, Connect2);
        ControlCommand(Soundboard v4, Track_77); // Say "Loading"
        sleep(1250);
        ControlCommand(Numbers, Track_2); // Say number Two
    }

    // Wait one minute before rechecking connections
    sleep(60000);
}

Explanation

• The script loops indefinitely using a while(true) loop.
• For each connection (0, 1, and 2) it checks if the EZB is connected using the EZB.isConnected(index) call.
• If not connected, the script re-establishes the connection with a corresponding ControlCommand(Connection, ConnectX) and plays some feedback messages via the Soundboard and Numbers skills.
• After each connection check, a short sleep() period is used for spacing, and finally, the script waits one minute before running again.

You can paste this refined script into an ARC JavaScript block and let it run. This should help periodically reconnect any lost connections.

Let me know if you have any further adjustments or questions!

The while (true) works great to keep your "refined" Javascript script looping. Thanks. this is the main thing I needed confirmed.

However there is not much difference from the script I wrote besides the "while (true)" addition and a few formatting fixes. I guess that mains I diid pertty good good. LOL.

There is one crucial problem with the script @Athena provided. None of the statements in the ControlCommand commands are defined with the needed parentheses (" "). Thanks goodness ARC gives me clues when a script has errors and wont run. so I had to add the parentheses abd the script runs great. Again thanks. Here is an example of one ControlCommand I had to fix:

Error:

ControlCommand(Soundboard v4, Track_77);

Fixed:

ControlCommand("Soundboard v4", "Track_77");

So, even though I haven't actually fixed the root problem I feel I've done enough troubleshooting and software adjustments to know this is a power or hardware issue like @DJ pointed out at first.

As stated above I've implemented a scripting "workaround" that will return the robot to normal by reconnect the EZB to ARC when ARC's connection to my EZBs are randomly lost. This only really happens every few hours when the robot is constantly powered up. I know this is not a true fix and only a bandaid. However I don't have the time or energy right now to take this robot apart again to confirm that this is a power issue by adding a dedicated powered USB hub instead of having my USB to Serial converter cables plugged directly into my mini computer's USB ports. I can however try to add one temporally by reaching up inside the robot just to see if it helps. Not an easy task. It's also possible this could be a bad converter cable or faulty EZB. I had both a bad EZB and converter cable before that acted like this. Also would need to take the robot apart to do replace the cables. My feeling is that the USB ports on the mini computer are underpowered like @DJ pointed out

So, in the meantime, I'll close this thread as resolved and report back later when I actually fix the underlying problem.

Thanks again for the great support and direction.

Thanks for the detailed update, Dave! It sounds like you’ve done some great troubleshooting and have identified that the disconnect issue is likely hardware- or power-related rather than purely software-based. Your workaround script is a clever way to keep your robot running in the meantime.

Here are a few points to consider moving forward:

• Hardware/Power Considerations:
  As you suspect, underpowered USB ports could be the root cause. A powered USB hub might provide the additional current stability your EZ-B controllers need, so it’s definitely worth testing even on a temporary basis.

• USB-to-Serial Converter & Cables:
  Since you mentioned you’ve had issues with both a bad EZ-B and a converter cable before, it might be a good idea to check the integrity of the cables if you decide to replace them later. Even a slight fault can cause intermittent disconnects.

• Next Steps:
  When you get a chance to try a powered USB hub, let us know if it improves the stability. If not, further investigation of the cables or even the EZ-B’s health might be required.

Thank you again for sharing your troubleshooting progress. Your update not only helps confirm that your workaround is effective while you figure out the underlying issue but also contributes valuable information for anyone experiencing similar problems.

Feel free to reach out if you have any more questions or need additional support once you get a chance to test the hardware approach. Good luck with the next steps, and thanks for keeping us posted!

@Athena, I know that I do have a "Print" command in the above script that signals that the EZB is disconnected. This does tell me that the disconnect has happened and the script is attempting to reconnect. However it's kinda tedious to look back through the list of reported events in the Script Manager window that are reported from all the scripts working from it.

I probably need to go through all my scripts in that Script Manager and remove all the print commands that are not really needed.

Is there another way to permanently log an event like a connection disconnect and it's time in a file in ARC or on the computer somewhere that I can look through? Probably triggered in the same above script that finds the disconnection?  If so, could you list the ways I could do this and how I can accomplish them?

Maybe just don’t print a successful connection status? That’s called an "everything is ok alarm" haha

only print when it’s disconnected and reconnects.