Using The EZB Stress Test And Results
I am using the EZB Stress Test robot skill in Synthiam ARC.
The instructions for the skill detail physically placing a jumper on the TX/RX pins on UART 0 to conduct the EZB UART test, which I have completed successfully.
I then created a new, clean project, started my robot, and connected to the EZB on connection 0 using a USB to Serial cable. Within the EZB Stress Test, I selected the "Enable Testing" button, and the console window confirmed that one EZB was connected and ready for testing.
However, when I initiated the UART test, it immediately failed. The test stopped, indicating there was no EZB connected, and the "Enable Testing" button was reset. In the console window, the UART Test displayed the number 4.
Importantly, despite the failure, the connected EZB did not disconnect, freeze, or require a reboot. Here is the logged information from that test:
Timestamp: 2025-12-11 22:18:09 UTC
ARC Version: 2025.12.03.00
OS Version: Microsoft Windows NT 10.0.26100.0
Base Directory: C:\Program Files (x86)\Synthiam Inc\ARC by Synthiam\
=== Exception Information ===
Type: System.Runtime.InteropServices.ExternalException
Message: Requested Clipboard operation did not succeed.
HResult: -2147221040
Source: System.Windows.Forms
TargetSite: Void ThrowIfFailed(Int32)
StackTrace:
at System.Windows.Forms.Clipboard.ThrowIfFailed(Int32 hr)
at System.Windows.Forms.Clipboard.SetDataObject(Object data, Boolean copy, Int32 retryTimes, Int32 retryDelay)
at System.Windows.Forms.Clipboard.SetText(String text, TextDataFormat format)
at System.Windows.Forms.Clipboard.SetText(String text)
at EZBStressTest.MainForm.button1_Click(Object sender, EventArgs e) in C:\My Documents\SVN\Developer - Controls\In Production\EZB Stress Test\EZB Stress Test\MY_PROJECT_NAME\MainForm.cs:line 49
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Here is an image of the ended UART test:
Additionally, the Stress Test Skill froze, requiring removal and reinstallation to initiate another test.
A similar issue occurred with the Audio test. The console window showed the failed Audio test result as number 16. When running this test and it fails, the connected EZB freezes and needs to be rebooted.
I will post the logged information from the failed Audio test in the next post.
Here is the logged information from the failed Audio test:
What do these results indicate?
Update:
This morning's run, after moving and shortening the above mentioned UART converter cable, failed. I was running the robot on it's regular ARC project. It ran for about 4 hours and Connection 0 disconnected once more.
Thanks to the Customer Service on todays update fix for the Stress test skill so it will now allow audio and UART testing of multiple ezbs simultaneously. This was a major reason I wasn't using this skill more for testing.
After setting all baud rates to 230400I I now have this skill testing all of my three EZBs at the same time with all tests running except the audio test. Sorry but the constant beeping is annoying. I don't have any audio being played by any of my EZBs anyway.
Great to hear the stress test is working.
To help diagnose your connection issue, we need to see your debug log. The debug log will show the last command and what ARC was waiting for during a disconnection. You can access the debug log via the top menu, where you select Workspaces. This page shows information about how to access the debug log: https://synthiam.com/Support/ARC-Overview/Virtual-Workspaces
By excluding debug log data, we're unable to provide advice on where to look to resolve your connectivity issue.
Hi. Thanks for the update to ARC. Nice update!
After updating ARC I started my robot project, connected the three EZBs to ARC and let it run. Within an hour I got two disconnects on Connection 0 in half an hour. Here's the ARC log for between start up and the disconnect: Please note that I have a script looping that sees the disconnects and then reconnects. The EZB does not need to be rebottled. Just reconnected.
You can read that log and see
WRITE timed out means your USB device disappeared. So the USB/uart adapters are disconnecting from the pc. There's also a problem with either your cable or the computer's USB port. Loose USB ports can cause issues.
-OR-
You have CTS and RTS connected to something on the UART adapter, and it doesn't know what to do. Maybe they're floating or something? Perhaps they're connected to an empty wire and acting like an antenna.
Either way, one of those two things is happening. You used to get time-out read errors; now you're getting write errors. It's easy to assist with software stuff, but I'm not in front of your robot to see how you have things wired, what kind of cables you're using, etc. I'm blind. But maybe the errors shifted from one problem to another?
-OR-
Maybe that brand of UART adapter has a buggy driver, and it just doesn't work very well.
*edit: scratch this comment. I see you are using 230400. For some reason I thought 256000.
ignore below Also - since you're not using audio on the ezb... use a more standard baudrate like 230400
that will remove any chance that the uart adapter can't adapt to the 256k baudrate
Lastly, it looks like you're testing with your project, so you haven't really ruled out anything strange there yet. I recommend continuing testing with the stress test robot skill.
Let it run overnight. Let it run for a long time.
Wiggle the wires while it's running and try to crash it. Wiggle the USB cable. Wiggle the uart cables. Wiggle things. Touch things. Shake things. Make it crash and find out what's causing it.
Do tests with the stress test because that's a consistent stream of data to test with. The stress test is a known parameter. It's something dependable that we can reproduce disconnects with once you figure out what's causing it.
Your project is unknown and random to me, so it adds far more complexity, and there's not much I can do to help. At least with the stress tool, I can see a log and know precisely what it's doing.
One more thing. Can you confirm the ezb and ARC are both set for 230400 baud? Because it will kinda-might-sorta work if ezb is set to 256000 and ARC is 230400 (vice versa). But they both need to be 230400 (matching).
@dj, I completely understand the challenges you have helping with remote issues like this. Expectedly home built hardware troubleshooting when you are the Software provider. I want you to know that your input and guidance has been very helpful and more appreciated then you know.
I can confirm that the setting on both sides, ARC and the EZB are set to 230400 baud. I also have the Bits Per Second in the all Com setting in Device set to match this setting. I don't know if that last step is needed but I doesn't seem right to leave that at the default of 9600 baud when I'm having problems like this.
I've started exclusively started using the Stress test now. I'll also double check that I have the latest driver installed for my USB to TTL COnverters. I'm pretty sure I do as I went over all this when I first started with this issue. The converter is a well respected brand with tomes of good reviews. It's running the a FTDI FT232RL Chip which is suppose to be one of the best and most reliable. Added to this I've tried several converters with the same issue happening.
I'm running the stress test on all three EZBs at once for the past few hours and will continue for the rest of the day into the night. I've wiggled around all connections and the connection held.
Again, thanks for hanging in there on this with me. I'll report back.