Unfortunately, that is how serial communication works. Serial/Uart has no sense of connection status. Serial transmits data, without having any verification that it was received. The only time the connection control could detect a disconnected serial connection is by pinging or probing the ezb and timeout while waiting for a response.

This could be done by using either a script command that queries a port status. Or a robot skill that queries the ezb, such as https://synthiam.com/Support/Skills/General/EZ-B-v4-Info?id=16059

OK, thank you. I do have a script that checks connection. I was hoping ARC could do automatically without me having a script looping and watching the connections.

With usb, the question would be how is it disconnecting? Because unless a physical wire disconnects, it is always connected. The wire determines the connection with it without the button being pressed. The connect button tells ARC there is a connection, when using usb.

Can you add more information as to how the usb ezb is disconnected? This would be the first item to fix before considering a form of watchdog.

Yeah I’d continue down the path that support had asked about how it can disconnect. A watch dog skill can be created but it sort of already does this with the temp/volt info skill pointed out earlier.

support is right about that a wired ezb connection can only be disconnected by unplugging the usb device or cutting the wire. As long as there’s a physical wire to the ezb, it’s connected forever.

Let continue discussing how it is disconnecting and see if we can fix that first.

Sure thing. Thanks for following up and asking.

I have a bunch of Sabertooth motor controllers that have Kangaroo x2 boards that adds position and speed control to them. The Kangaroo's are attached to several EZB v4's through the EZB's Uarts. When I first start the robot I need to:

*Initialize the uarts that the Roos are connect to.

*After I Initialize the uarts I need to send Simple Serial commands through the EZB's Uarts to start the Sabertooth's motor channels.

*Then I need to Home the motors attached and being controlled by the Kangaroos and Sabertooths (or is it Saberteeth? LOL)

*Only then can I send Simple Serial position and speed commands from other ARC scripts to move the DC motors on my robot.

I have all that setup routine in one INT script that runs when I first power up and start up the robot. The timing of each startup command needs to be correct with the proper pauses to let all the devices finish their setup. Usually only 500 MS, give or take, but it took a little testing to find the proper timing.

During this script testing process I was having problems with the EZBs locking up and disconnecting after trying to send commands through the UART. I'd have to power down and restart the EZBs. My feeling is when this happened I wasn't giving the Uart enough time to Initialize before sending another command through it. It would have been nice to have a visual tip that the connection was gone when this happened instead of having to guess and test the connection. I eventually got the sleep timing correct in the INT script and the startup process executes completely and smoothly now.

Thanks again.

Ah I see. Locking up is actually because the ezb is waiting for data. I bet the red led is on. If so, that means it’s waiting for data.

so what’s happening is that data is attempted to be read but it’s not available in the buffer. So it’s sitting waiting for the data forever.

if you sent a command to read 5 bytes, it’ll wait for ever for the 5 bytes to arrive to the ezb.

im guessing we need to look at the scripts, because they will complete the story. The roo and saber tooth has some serial mode that transmits text (ie 400p\n) and thats the made for humans, not code. So more attention must be given to the scripts to properly accommodate the data.

@DJ, Thanks for the input. Actually, the script in question isn't asking for any data. It's sending data. I don't have the actual script on this computer to copy but here's what it does:

*Initialize the uart that the Kangaroo is connect to.

*Send a Simple Serial commands through the EZB's Uarts to start the Sabertooth's motor channel the motor is attached to.

*Then the script sends a Simple Serial command to the Roo that homes the motor so the Roo knows where it is. The Roo will watch the encoder on the motor shaft until it hits a limit switch.

The EZB would become unresponsive when I used this script. I did not have any sleep commands between the command to Initialize the uart, start the Sabertooth motor channel or home the motor. Once I placed sleep commands in between these commands the EZB kept it's connection and the devices executed the commands. The EZB stayed responsive. Oddly when I placed sleep(500) between the commands the problem persisted. When I bumped it up to sleep(1000) everything worked as needed. I haven't had a chance to play around with the sleep() commands to confirm all this or fine tune the pauses.

My thoughts are that I sent a command through the Uart before it was fully Initialized.

I'll do more testing later to confirm this and perhaps get better information to share. I'll also share the script at that time. Thanks!!

The initialization is complete the moment the init command is completed. It doesn’t take additional time. So if your script is

init uart
send data 

In that order, it’s fine.

When the ezb locks up, is the red light on?

lastly, what baudrate is the ezb using? It could be the ezb locking up waiting for data to send but it’s missing it due to a physical transmission issue. Sometimes a slower baudrate helps with that. What baudrate is it using?