Step one, Last night I disabled usb suspend . I let the robot sit running it's personality scripts for a few hours. No good. Didn't work. I had one of the Com ports disconnect.

Today I'll move on and try other suggested fixes.

Thanks again for the support.

It sounds like you’re methodically working through the possible fixes - great job so far! Since disabling USB selective suspend didn’t resolve the issue, here are a few additional steps to try:

• Powered USB Hub:
  If you haven’t already, try connecting your EZ-Bs via a powered USB hub. This ensures that the EZ-B controllers are getting a steady supply of power and can help prevent brownout issues.

• Baud Rate & Device Manager Settings:
  Double-check the baud rate setting both in ARC and in the device properties (via Device Manager) for your USB-to-serial converters. Sometimes lowering the baud rate can improve signal integrity. Also, verify that none of the USB ports have conflicting power management settings that might be causing intermittent drops.

• Cable Quality & Connections:
  Inspect your USB-to-serial cables to make sure the connectors are secure and the cables aren’t damaged or running too close to any power lines (which could cause EMI). Testing with a different cable can help rule out cable issues.

• Monitor the Connection Diagnostic Log:
  When the disconnect happens, have a look at the Connection Diagnostic log in ARC. It might provide additional clues as to whether it’s a communication error or perhaps a power-related event being logged.

• Consistent Issue with a Specific COM Port:
  Since you mentioned one COM port disconnects, see if it’s always the same one. If so, you might experiment with swapping the cables and COM port assignments to determine if the issue follows the physical port or the EZ-B itself.

Let me know how it goes as you try these other suggestions. If you have any log details or additional observations, feel free to share so we can dig a bit deeper into the problem. Happy troubleshooting!

@Athena, you and @DJ mention checking the Connection Diagnostic Log. Where do I find that and bring it up to view?

You can view the Connection Diagnostic Log right within ARC once you've added the Connection Diagnostic Skill to your project. Here’s how to access it:

• Step 1: Add the Skill
  If you haven’t already, go to Project > Add Skill > General > Connection Diagnostic. This skill opens a window with verbose logging for EZ-B communication.

• Step 2: Open the Log Window
  Once the skill is loaded, you'll see its window with diagnostic controls. On this window, there’s a text field that displays all the log messages. You can also use the buttons (such as "Copy Log to Clipboard") available at the top of the skill window.

• Step 3: Monitor Log Activity
  When your EZ-B disconnects, review the log in that window. It may provide clues or error messages indicating why the disconnect happened.

For more details, check out the Connection Diagnostic Skill page on Synthiam’s support site: Connection Diagnostic Skill.

Does this help clarify where to find and view the log? Let me know if you have any more questions!

Update, discovery and question:

I've tried all the software related suggestions so for. I wanted to do the easy stuff first before I have to take the robot apart and start replacing or adding hardware. I still have the disconnect issue with two of my three connections.

As I mentioned I had already tried disabling the USB selective suspend setting. Now I've lowered all the baud rates to 9600 in ARC's connection skill, the EZB's settings through the interface and also in Device Manager unter the Ports (Comm) tab ( I think that's where I found that setting). I also lowered the USB latency for the USB to serial converters I found in Device Manager in the USB tab from it's preset setting of 16 down to 1. This was a suggestion I found on the internet when researching this connection loss problem. Nothing helped.

So as suggested I next added the Connection Diagnostic Skill to view the log to see what's going on in the background. I was surprised to see a long string of very fast set of reading continually zipping by. Since they looked like gibberish numbers to me I finally tracked down what they are. I have 6 or 7 momentary buttons on my robot that are monitored for a button push by ARC using the ADC ports. Each button has it's ARC own JavaScript script that runs all the time and loops to watch the button's ADC reading.

I'm not sure how these ARC scripts decide how fast to read the ADC Voltage. I know I have a ADC skill added to my project for each button needing to be watched. In that skill I have the interval set to 500 (1/2 second). Also I have these ADC skills always paused unless I need to look at the reading.

Here is a copy of one of the scripts that loop to watch for a change in the ADC voltage going through the button:

while (true) {
print("Waiting for Personality toggle button (Gamma 101) to be pushed...")
// Wait for ADC value to indicate Personality toggle button (Gamma 101) was pushed
//to turn Personaluty off or On
ADC.waitForHigher(2, 200);
var personality = getVar("$Personality")
sleep(200)
if (personality == 0) { //0 means Personality is running.
turnOffPersonality()
}else if (personality == 1) {//1 means Personality is Paused.
turnOnPersonality()
}
}

function turnOffPersonality(){
//Personality toggle Momentary button (Gamma 101) was pushed. Will turn Persponality Off (PauseOn).
ControlCommand("Personality Generator", "PauseOn");
sleep(4000); //Holds shript here until ADC reading returns to zero before switching to other function
ControlCommand("Soundboard v4", "Track_24"); //Will do "Raspberries" sound
print("Personality is Off");
setVar( "$Personality", 1); //Sets Global Variable so next button push will turn Personalilty On
}

function turnOnPersonality(){
//Personality toggle Momentary button (Gamma 101) was pushed. Will turn Persponality On (PauseOff)
// Perform actions after Personality toggle button (Gamma 101) was pushed
ControlCommand("Personality Generator", "Pauseoff");
sleep(4000); //Holds shript here until ADC reading returns to zero before switching to other function
ControlCommand("Soundboard v4", "Track_23"); //Say "Green and GO"
print("Personality is On");
setVar( "$Personality", 0); //Sets Global Variable so next button push will turn Personalilty Off
}

Is it possible that these 6 scripts running loops watching the ADC readings from the buttons could cause my disconnection issue? Am I flooding the channel? If so, would slowing down the ADC read interval help or stop the disconnection? I don't want to slow it down too much and miss a button push.

Here's a video short of the Connection Diagnostic Skill displaying these results. Sorry about the double shot at the end. 

It definitely sounds like you’ve uncovered an important detail in your system’s behavior. Here are a few things to consider regarding the ADC reading loops and their possible impact on the connection:

1. Message Traffic Overload:
   Each of your scripts continuously loops and calls functions like ADC.waitForHigher(). Although these functions are designed to wait for a change (with a short timeout), having six or seven such loops running in parallel can cause a significant amount of communication traffic between ARC and the EZ-B controllers. This extra load might be overwhelming the serial channel on the USB-to-serial converters, which in some cases can contribute to disconnection issues.

2. Flooding the Channel:
   If the scripts are sending frequent messages or printing status outputs (such as the print() statements) repeatedly, it could flood the connection-especially on USB links that might have tight bandwidth or latency limits. The quick succession of ADC data in the diagnostic log is a clue that there’s a lot of activity taking place, which might be impacting overall communication reliability.

3. Balancing Responsiveness & Stability:
   You’re rightfully concerned about slowing down the ADC polling too much and missing a quick button press. One approach is to try increasing the polling interval or adding additional delays (even if just a short 100-200 milliseconds extra) to reduce the traffic without making the button response feel sluggish. In other words, a slight delay might smooth out data flow without noticeably impacting responsiveness.

4. Event-Driven or Debounced Logic:
   Consider implementing a debounce routine or using an event-driven approach rather than constant polling. For instance, you could:

   • Check the ADC value at a modest interval and only send a command (or print to the log) when a change is detected.
   • Use a flag to ensure that once the button is detected, the script waits a bit longer before rechecking. This can prevent a burst of messages from repeated triggers if the button’s voltage is fluctuating.

5. Testing Suggestions:

   • Try temporarily increasing your ADC read interval by a small margin (for example, change the interval from 500ms to 750ms or 1000ms) in one of the scripts to see if the disconnections become less frequent.
   • Alternatively, consider conditionally printing to the log only when a meaningful change occurs rather than on every loop iteration.

To sum it up, yes-it’s quite possible that your multiple ADC reading loops are contributing to the problem by flooding the communication channel. Experimenting with slightly slower polling or a more event-driven approach might help reduce the traffic and improve connection stability.

Let me know if these suggestions help or if you have any more questions as you work through this!

@Athena, Where do I change ADC polling value of each button? Would that be done in the ACD Value Skills I have uninstalled but paused? I now have them all set to 500 ms.

OK, the rapid ADC polling doesn't seem to be the cause. I turned off the scripts that were looping and watching the ADC values. I still got a disconnect for one of my EZBs.

I guess I need to move to hardwear next. I'll see if a powered USB hub will do the trick. Sadly the computer and usb to Serial converter cables are inside the robot. I'll have to dig around or even take it apart (again) to do this next part. Ugh.