Problem with USB Serial port.. Not a HB issue, but is.

[Steve Horn]

This is (I'm pretty sure) not a HB issue directly, but my HB implementation is being affected. I have an Arduino connected to the HB server to perform several tasks associated with real world devices - projector lens sled, and motorized blinds. There are tasks within HB that sends commands the the Arduino over its USB seral port, via the HB generic serial port interface. Recently, the "link" between the PC and the Arduino has stopped. (The arduino still runs/functions outside of its serial connection, but the serial I/O has stopped.) Commands from HB fail as well as commands from the PC outside of HB (i.e. from terminal emulator programs). Rebooting the Arduine has no effect, or a restart of the HBSERVER. Only a PC restart will correct the problem. This tells me its a basic serial port, or USB serial port issue.
After a reboot, the connection is maintained for a day or less. Hard to establish when it goes from working to not. But a Reboot each morning, typically, is required. On occasion, disabling and enabling the port in Device Manager has fixed it, but not always.
It should be noted at when this was installed several years ago it worked flawlessly for many months. Only within the last few months has it become unreliable. What changed? That trail is long cold.
Running WIN7 PRO, latest version of HB (likely not an issue though).
Does anyone have an idea of how to diagnose this?

[ScottBot]

I know I've had issues in the past with something grabbing the com port on startup before HB can open it. Does the Serial Hardware Interface enable ok?

Have you tried a different serial port?

[TonyG]

Not sure if this helps, but I had issues with Arduino boards and serial connection with Girder 6. I lost the serial connection but could fix by reboots or a little reset routine using putty.

The problem was dependent on the type of Arduino. Standard Uno type were OK, but hit the issues with the newer sparkfun pro-micros - and other boards using the ATmega32U4, that does away with the separate FTDI chip, but gains native HID. What arduino are you using?

Ron replicated the issue by purchasing a sparkfun pro-micro:

OK Got the pro-micro and indeed it is as you describe,.. and the good news is I have been able to trace the issue. (DTR/RTS were not being set, which didn't matter for most devices, but this one actually cares!). New Girder build is baking...

Thread here: https://www.promixis.com/forums/showthr ... ht=arduino

[Steve Horn]

Scott: the hardware serial port enables ok. Assigning another serial port is difficult. Housebot's list of ports in the hardware serial port interface setup is differnt than that of what Windows sees as available ports. Normally this would not be a problem but i am using MANY serial ports - both USB and RS232 - for control of home theater, Insteon PLM, Arduino, CANAKIT I/O. Getting a match between what HB says is assignable and what Windows and the serial device says is available is tricky.

TonyG: nope, this a "genuine" Arduino Uno. Interesting though that this might be an issue with other versions, and clones. I'll read up on the other thread once im fully awake.

[TonyG]

Assigning another serial port is difficult. Housebot's list of ports in the hardware serial port interface setup is different than that of what Windows sees as available ports.

Steve, not sure if you already do this, but I had similar issues for Housebot serial connections that connect to "virtual com ports" (in my case a GPS device / Frankson GPSGate splitter, that sends GPS sentences on differently assigned com ports) - these don't always show up as a h/w com port.

I got around this by manually creating "null" com ports - and then assigning them in housebot and then the respective GPS device. In case you haven't tried this:
1) Control Panel
2) Device Manager
3) At top of device tree, is device (PC) name > right click on this
4) Add Legacy Hardware
5) Install the H/W manually
6) From list, select ports > communications port

The device is created, but will have an exclamation mark. That's fine, as you have a new com port Housebot can use. Then it's down to some work on the actual virtual serial device itself...

Just in case that is any use for your devices...

[Steve Horn]

TonyG, well thats all new to me! And cool! Not sure why its even necessary, but its become clear to me that some things that should be straightforward in Windows and Windows w/Housebot aren$t always.
Thanks for the tip!

[Steve Horn]

Update: I disabled two what appeared to be competing tasks that send commands to the Arduino over the serial port. For several days, the port stayed functional ; i could manually send commands via simpler tasks. I then re-enabled one of the disabled tasks and the port locked up sometime before the next morning. The apparently offending tasks don't do anything exotic. They just open or close the blinds based on sunrise/sunset, while checking status properties to see if the blinds are already open or closed. I replaced the open and close tasks with simpler time-of-day condition tasks and. so far, things are working. So, best as I can conclude, either the two tasks were somehow competing and as a result overloaded and locked up the port. Or maybe just one, due to BAD CODE, was doing it. Not ready to close the book on this yet, but maybe soon. Knock on wood.

edit and update: failed again. Getting error msg in HB error log: "Error GetoverlappedResults() in WriteFile()" with a time stamp of the time the task ran.
When I restart HB, I see a msg in the system log: "SetCommState()". And restarting HB does not correct the issue. Restarting Windows 7 does.
Disabled the PM task. AM task still enabled.

[ScottBot]

Getting error msg in HB error log: "Error GetoverlappedResults() in WriteFile()"

Here is an updated serial port hardware interface that will give a little more info in that trace message on why that is failing (let me know the error code it shows). Unzip and copy into your HouseBot/Plugins/Interfaces directory over the old one. Then restart HB. The info may be useless, since it shouldn't be failing and is probably a glitch with the actual driver.

[ScottBot]

Steve,

When did you first start seeing this problem?

[Steve Horn]

That trail is long cold - months ago, maybe 3-4. And, IIRC, its intermittent. Will work for weeks, then fail repeatedly after a day or so. And with no known changes on my part to the tasks or anything else that (I think) might affect it. Disabling the two tasks that are referred to in the earlier post SEEMS to have stabilized it. But that may just be coincidental. Need to do a longer test.

Haven't updated the serial port interface yet. Will get to it later today.

[Richard Naninck]

I have had this problem with USB to serial devices that are extended using a CAT 5 extender. Out of the 3 extenders I have, 2 of them halt my comms after a day or so. Not sure how your Arduino is connected though. Maybe try a different USB port on a different hardware hub.

Last week I exchanged a 4 TB harddrive because it didn't get recognized anymore after three years of operation. The new harddisk showed the same problem. Turned out to be old SATA cables and not even the one connected to the faulty HD. After changing cables, all is fine again even on the old harddisk.

Just saying that old hardware / cables may be a problem here as well.

[Steve Horn]

Intersting... And a little spooky. I had wondered about the USB cable, and that may still be a possibility. Although Scott suggested making a change to the task based on a long shot hunch. So far, the Arduino and related tasks are working - 4 days. The Arduino is "directly" connected; no hub or other extension involved. But thats good to know, as I'm about out of USB ports on the box.

[Steve Horn]

Update: i swapped out the Arduino, loaded the code into the replacement - no problem, the IDE was able to connect and load - and all is good now. Been running without issue for weeks. I suppose the original Arduino got flashed somehow and was no longer able to communicate with the outside world via its USB, although the internal code responded to switch closures connected to its i/o. Case hopefully closed.