@DJ, so obvious, so brilliant. LOL, Thanks!

Below is some information and a couple of options you might consider so you don’t have to scroll through the Script Manager window to review connection events.

Option 1: Log Events to a Notepad Skill

If you want ARC to permanently keep a record of disconnects (including the time each occurred), one approach is to use the Notepad skill as your log file. You can update the Notepad with a new line each time a disconnect is detected. For example, in your JavaScript you can do something like this:

// Helper function to append a message to the Notepad skill
function logEvent(message) {
  // Get the current timestamp
  var now = new Date();
  var timestamp = now.toLocaleString();
  var logText = timestamp + " - " + message;

  // Here, we assume your Notepad skill is titled "Notepad"
  // Append the log message. The actual details depend on how your Notepad skill accepts updates.
  // For example, you might use a  ControlCommand or a script action provided by the skill. 
  ControlCommand("Notepad", "AppendText " + logText);
}

// Example usage in your connection check:
var conn_0 = EZB.isConnected(0);
if (conn_0 === true) {
  // Optionally you could skip logging success events:
  // logEvent("EZB 0 is connected.");
} else {
  logEvent("EZB 0 is disconnected; attempting reconnect.");
  ControlCommand("Connection", "Connect0");
  sleep(500);
  ControlCommand("Soundboard v4", "Track_77");
  sleep(1250);
  ControlCommand("Numbers", "Track_0");
}

This function uses the current date/time to create a timestamp and then sends an "AppendText" command to your Notepad skill, which you can think of as your live log file. (Note: how Notepad accepts commands might vary by your ARC configuration; please adjust the ControlCommand parameters as needed.)

Option 2: Write to a File Using JavaScript (Advanced)

The ARC JavaScript environment is a protected scripting environment so it typically does not allow full file I/O access as in Node.js. If you need to write directly to a file on your computer, you would have to examine ARC’s documentation or use a custom robot skill that exposes file writing functionality.

For instance, if you create a custom skill (learn more here: Create Robot Skill), you might expose a command that writes text to a file. Then your script could call that ControlCommand with the proper parameters to log the event. This advanced method requires additional development but it offers a more permanent log saved on the hard drive.

Additional Tips

• Print Only on Errors: DJ_Sures suggested and you agreed-only print/log events when a disconnect is detected instead of printing a message for every successful connection. This will reduce noise in your logs.

• Timestamp Inclusion: As in the example above, always include a timestamp so you can see exactly when each disconnect or reconnect occurred.

• Review ARC Logging Settings: ARC itself does create an event log that might be accessible from the system. You could check ARC’s documentation or settings (via Synthiam’s website at ARC Downloads) to see if there is an option to persistently save these logs aside from what your scripts print.

Let me know if you need further clarification on these options or help fine-tuning your script!

Update:

I've installed a powered USB hub (3.0 Hub). I still am experiencing Com Ports 0 and 2 disconnecting. Mainly Com Port 0 and on occasion Com Port 2.

Com Port 1 seems very stable and I've never had an issue with it disconnecting.

While looking over ARC's  Connection Skill's settings window under the COM/USB Connections tab I noticed that I have the RTS Enabled checked. @Athena (or anyone else), could this cause my issue?

Nice troubleshooting so far, Dave - you’re on the right track. Short answer: yes, RTS can cause problems in some setups, but it’s not usually the root cause of random COM disconnects. Here’s what RTS does, why it might affect your EZ-B connections, and a prioritized checklist of tests/fixes to find the real cause.

What RTS/DTR do and how they can affect devices

• RTS and DTR are modem control lines. Enabling them causes the USB-serial adapter to assert those control signals when the port opens or during communication.
• Some devices (or adapters wired to the device) use these lines to reset, wake, or enable hardware. If a control line toggles unexpectedly it can reset the target or change the adapter’s state, which may look like a disconnect.
• On some Arduino-compatible boards, DTR is intentionally wired to cause a reset on open - that’s why some devices require DTR/RTS checked. On other devices it’s not needed and can create unintended behavior.
• Faulty or unusual adapters (or adapters with drivers that toggle signals) can behave differently. So RTS could be a trigger, but it’s often one of several culprits (power, drivers, bad cable, hub, adapter, or EZ-B hardware).

Practical tests (in order - quick to try first)

1. Disable RTS (and DTR if enabled) for the problematic connection(s)

   • Project Add Skill Connection CONFIG for that index COM/USB Connection tab uncheck RTS (and DTR if not required).
   • Restart the connection (Connect/Disconnect) and monitor. If disconnects stop, RTS/DTR was likely interfering.
   • If a device actually requires DTR (e.g., certain Arduino Leonardo), only toggle RTS first.

2. Test direct PC connection (bypass hub)

   • Plug one problematic USB-serial cable directly into the PC USB port (no hub). Run until the time window where disconnections used to happen.
   • If it becomes stable, the hub or hub port/power is suspect (even "powered" hubs can be poor quality).

3. Try different USB port(s) on the PC

   • Prefer back-panel motherboard USB ports (they’re usually more reliable than front-panel or hub ports). If the PC supports USB 3.0 and the adapter is USB 2.0, try both kinds.

4. Replace the USB-serial adapter or cable (swap with COM 1 adapter)

   • Swap the adapter currently on COM0 with the adapter from COM1 (which is stable). If the problem follows the adapter, the adapter or driver is likely bad.

5. Drivers and Windows power settings

   • Update the USB-serial driver (FTDI / Prolific / CH340) to latest from manufacturer. Avoid generic drivers from Windows Update if possible.
   • Device Manager Universal Serial Bus controllers right-click each USB Root Hub Properties Power Management uncheck "Allow the computer to turn off this device to save power."
   • Control Panel Power Options Change plan settings Change advanced power settings USB settings USB selective suspend setting set to Disabled.
   • Set Windows power plan to High Performance while testing.

6. Check Windows Event Viewer

   • Event Viewer Windows Logs System and look for messages about USB device disconnects or COM port resets around the time of the failure. That can hint whether Windows is dropping the device or the device is resetting.

7. Use Connection Diagnostic and logs

   • Add the Connection Diagnostic skill and capture the verbose log when a disconnect occurs. The diagnostic output often shows the cause category (timeout, device reset, etc.).
   • Connection Diagnostic skill: https://synthiam.com/Support/Skills/Communication/Connection-Diagnostic?id=16164
   • General connection troubleshooting doc: https://synthiam.com/Support/troubleshooting/Connection-Troubleshooting

8. Check EZ-B firmware, port wiring, and power on the EZ-B

   • Confirm EZ-B firmware versions are current and consistent across boards: https://synthiam.com/Support/Hardware/EZ-B-v4
   • Ensure the EZ-B supply and grounds are solid. Intermittent brownout/voltage variation can cause modules to reset and the host to drop the COM port.

Other suggestions and final checks

• Try a different brand USB-serial adapter (FTDI is usually the most reliable). Cheap CH340/Prolific clones are often the cause of flaky behavior.
• If you suspect heat/long uptime causing failure, try running extended tests in a bench environment (not inside the robot) to see if ambient heat or vibration contributes.
• If RTS toggling is required by a device, you can create a small test script that toggles RTS only when necessary rather than leaving it asserted. But usually leaving RTS/DTR unchecked for EZ-B serial connections is fine.

Quick recommended first steps for you right now

1. Uncheck RTS (and leave DTR how it was unless you know it’s required). Monitor for a few hours.
2. If still disconnects, plug COM0 cable directly to the PC (no hub) and test.
3. Try swapping the COM0 adapter with COM1’s adapter. If it follows the adapter, replace it.

Would you like me to

• give step-by-step screenshots for disabling RTS in the Connection skill config?
• provide a small script to log disconnect times into your Notepad skill when a disconnect happens (so you don’t need to comb Script Manager)?
• suggest a reliable USB-serial adapter model and driver links to try?

Tell me which adapter models you’re using for COM0/1/2 (FTDI, Prolific, CH340, or built-in) and whether the adapters are identical - I’ll tailor the next troubleshooting steps.

I unchecked the RTS option with no improvement. More troubleshooting today.

Nice progress, Dave - good work ruling out RTS so far. Below I’ll give a prioritized troubleshooting checklist you can run through next, plus two ready-to-use JavaScript logging scripts you can drop into your Script Manager to permanently log disconnects (one appends to the Notepad skill, the other writes to a CSV-style file using an ARC-friendly approach). I’ll also list the data I need from you to make the scripts match your exact ControlCommand syntax.

Troubleshooting checklist (prioritized)

1. Swap adapters/cables (quick, high value)

   • Swap the USB-to-serial adapter from the stable COM1 to COM0. If the problem moves to the other COM port, the adapter or cable is suspect.
   • If you have a spare FTDI-based adapter, try that first (FTDI is the most reliable).

2. Direct-to-PC test (bypass hub)

   • Plug the problematic cable straight into a back-panel USB port (avoid front-panel hubs). Run until the usual disconnect time window. If stable, something with the hub/port was still at fault.

3. Replace the cable temporarily

   • Even small faults cause intermittent drops. A new/shielded cable is a cheap test.

4. Power & EZ-B supply

   • Confirm the EZ-B power rail is stable (voltage under load). Brownouts/reset on the EZ-B will look like host disconnects.
   • If you can, bench test with the EZ-B-powered from a known-good bench supply outside the robot for an extended run.

5. Windows power settings & drivers

   • Device Manager Universal Serial Bus controllers For each USB Root Hub: Properties Power Management uncheck "Allow the computer to turn off this device to save power".
   • Control Panel Power Options Advanced USB settings USB selective suspend Disabled.
   • Set Power Plan to High Performance while testing.
   • Update adapter drivers (FTDI/Prolific/CH340) from vendor sites (not generic Windows Update clones).

6. Device Manager / Event Viewer

   • When a disconnect happens, open Windows Event Viewer Windows Logs System. Look for USB disconnect or driver-error events at the same timestamps.

7. Connection Diagnostic + ARC status logs

   • Enable and capture logs with the Connection Diagnostic skill when a disconnect occurs (it gives verbose communication traces).
   • Also copy ARC’s bottom status window (Copy button) into a log after a failure.

8. EMI / cable routing & USB 3 interference

   • Route serial cables away from motor power wires and high-current supplies.
   • If using USB 3.0 ports or a USB3 hub, try a USB2 port/hub; some USB3 controllers can induce RF noise that affects some devices. Shielded/shorter cables help.

9. EZ-B camera port usage caution

   • You mentioned the USB-serial is connected to the camera port. Verify there are no camera/serial conflicts on that port and that the EZ-B firmware supports serial on that port reliably.

10. Long-run bench test

• Outside the robot in a cooler, controlled setup, run a 24+ hour test with the same traffic pattern to see if heat/vibration or long uptime reproduces the disconnect.

Helpful links

• Connection Diagnostic skill: https://synthiam.com/Support/Skills/Communication/Connection-Diagnostic?id=16164
• EZ-B v4 firmware/manual: https://synthiam.com/Support/Hardware/EZ-B-v4
• Connection troubleshooting: https://synthiam.com/Support/troubleshooting/Connection-Troubleshooting

Logging options (recommended)

• Option A (easy): Append disconnect/reconnect events to a Notepad skill so you don’t have to scroll Script Manager.
• Option B (file): Save a simple timestamped CSV file to disc via an ARC-compatible command or a small custom skill (if you want system files). I’ll give a simple ARC-friendly approach that usually works from JavaScript by calling a ControlCommand that your custom file-writer skill would accept. If you don’t want to build a skill, use Option A.

Script A - Append to Notepad (recommended, easiest)

• Drop this into a JavaScript script in Script Manager. Update the ControlCommand lines to the exact working form you've used in your project (see note after code).

// Looping connection monitor - logs disconnects to Notepad and attempts reconnect
while (true) {
  // Check connection indexes 0..2
  for (var idx = 0; idx <= 2; idx++) {
    var connected = EZB.isConnected(idx);
    if (!connected) {
      var now = new Date();
      var ts = now.toLocaleString();
      var msg = ts + " - EZB " + idx + " disconnected. Attempting reconnect.";
      print(msg);

      // Append to Notepad skill - adapt  ControlCommand syntax to your project
ControlCommand("Notepad","AppendText|" + msg);

      // Attempt reconnect using your Connection skill command (match your syntax)
ControlCommand("Connection","Connect" + idx);

      // Example using the variant 2 string style:
      ControlCommand("Notepad","AppendText|" + msg);
      ControlCommand("Connection","Connect" + idx);

      // Give time for reconnect and any startup messages
      sleep(2500);
    }
  }
  // Wait before checking again
  sleep(1000);
}

Notes for Script A:

• Replace ControlCommand lines with the exact form you use (the form that successfully runs in your project).
• This script avoids printing connection-success messages to reduce noise (only prints on disconnect).

Script B - Write to a CSV file (requires file-write support)

• ARC JavaScript typically cannot write arbitrary files unless you have a skill that exposes file I/O. If you have or want a small robot skill that writes files, use a ControlCommand like:

// Example: send a "WriteLog" command to a custom FileWriter skill.
// Requires a FileWriter  robot skill that responds to "WriteLog|<text>"
while (true) {
  for (var idx = 0; idx <= 2; idx++) {
    if (!EZB.isConnected(idx)) {
      var ts = new Date().toISOString();
      var entry = ts + "," + "EZB" + idx + ",DISCONNECT";
      print("Logging to file: " + entry);
      ControlCommand("FileWriter","WriteLog|" + entry);
      ControlCommand("Connection","Connect" + idx);
      sleep(2500);
    }
  }
  sleep(1000);
}

If you’d like, I can provide a small FileWriter robot skill template and step-by-step instructions to add it to ARC (Create robot skill -> add a simple file-write action). Creating that skill requires a bit more setup but gives you permanent files on disk.

What I need from you to customize things

1. Which USB-serial adapters are you using for COM0/1/2? (FTDI / Prolific / CH340 / built-in)
2. ARC version and Windows 11 build (ARC Help -> About, and Windows winver output).
3. EZ-B firmware version for each controller (EZ-B skill status shows firmware version).
4. If you want, paste a short log snippet from Connection Diagnostic for a single disconnect event (I can parse it for hints).

If you want, I can:

• Provide an exact ControlCommand line to append to Notepad if you paste one working ControlCommand you already have (so I can mirror the style).
• Walk you step-by-step to disable USB power-saving with screenshots.
• Suggest a specific FTDI adapter model link to try.

Next recommended action right now

• Run Script A (adapt ControlCommand style if needed) and let it log a few disconnect events; then paste a couple of Notepad lines here or the Connection Diagnostic output and I’ll analyze timestamps and suggest the next hardware step (swap adapter or suspect EZ-B).

Want me to provide the exact ControlCommand lines for your project? Paste one example ControlCommand from one of your working scripts and I’ll make the logging script match it exactly.