HouseBot

"GetOverlappedResults()inWriteFile()"?
I have added a hardware interface using the Generic Serial interface. The external device is a microcontroller with a simple ASCII 2 way protocol - receives a one line command from HB and sends a status response. What I've found is that it works as designed ONCE after a HB server start-up (or possibly a PC reboot), But after that I see the above message in the error log. Unfortunately I cannot restart HB without rebooting because HB never fully goes away when I shut it down; I have to go into Process Explorer to kill the process. And when I do that the Hardware Interrupts process takes over the CPU and I have to pull the plug. Never have eliminated that issue, which existed before this latest interface add.

How are your hardware settings set?

- NULL Character Replacement
- Received Data Serial Device Destination
- Response Timeout (ms)

As for HB not being killed properly, sounds like something doesn't unload and keeps your process running. Any idea what binds HouseBot?

Richard Naninck wrote:How are your hardware settings set?

- NULL Character Replacement
- Received Data Serial Device Destination
- Response Timeout (ms)

As for HB not being killed properly, sounds like something doesn't unload and keeps your process running. Any idea what binds HouseBot?

- NULL Character Replacement = 255
- Received Data Serial Device Destination = Arduino (the micro/device)
- Response Timeout (ms) = 500ms
(Pretty much the default settings. The HB device received data property does reflect the data sent to it by the micro the one time it works.)

Re the Housbot kill, dunno, has been an ongoing problem for years. And from what I've read here, not limited to me. When I go into Process Explorer to kill it, PE does not indicate that there are other apps running as part of that "tree".

(Edited to correct spelling in subject line. Too early.)

What happens if you decrease the response time to say 50 or 100ms?

Where do you see the error: "GetOverlappedResults()inWriteFile()"? In a log, dump or...?

-------------

Do you run scripts using third party COM objects like an sql dll for your winamp jukebox?
Did you ever try to debug this by disabling running scripts etc.
I would start HB and disble just all tasks, devices and scripts and then try to kill it and see what happens. If it cleans up, start enabling devices again and kill HB inbetween each action. That way you could isolate the problem in ample time.
If the above doesn't work for you, something else must be a problem in your system. I presume you run HB on a single cpu core and the OS is Win XP?

Richard Naninck wrote:What happens if you decrease the response time to say 50 or 100ms?

Where do you see the error: "GetOverlappedResults()inWriteFile()"? In a log, dump or...?

Will chg that parm when I have more time to work with it - tonight.
Messages are in the error log. I started a hardware interface trace last night but have not looked at it yet. Tonight.

-------------

Richard Naninck wrote: Do you run scripts using third party COM objects like an sql dll for your winamp jukebox?
Did you ever try to debug this by disabling running scripts etc.
I would start HB and disble just all tasks, devices and scripts and then try to kill it and see what happens. If it cleans up, start enabling devices again and kill HB inbetween each action. That way you could isolate the problem in ample time.
If the above doesn't work for you, something else must be a problem in your system. I presume you run HB on a single cpu core and the OS is Win XP?

I suspect there is an sql dll for jukebox; never have looked. Will try the 'disable' routine, maybe tonight.
Yes, single CPU XP box.

Update: changed the response timeout to 50 ms and that helped somewhat. One command to the micro worked repeatedly but the other of the two did not. They only differ by one letter: 0,G,B,X,X vs. 0,G,F,X,X. I removed the two X placeholder parms being sent with both commands and now both work. Can't explain that.

Regarding the 'Can't shut HB down gracefully' issue. I disabled/stopped all scripts. No help. Looked in Process Explorer for another process that might be associated with HB (i.e. an SQL DLL or whatever) but did not find any. Will work with it more.

OK, one down and one to go.
Sometimes you don't want to explain;)
I will think some more about the HB shutdown issue and report back if I think of something.

Richard Naninck wrote: Sometimes you don't want to explain;)

That's what I thought. I'd like to know what the error msg means but I'm willing to let it go.

The GetOverlappedResults() error indicates that there was an issue sending the data asynchronously to the device. For you to see this, it means that the data was sent to the device and it reported the operation pending, but never completed it (or something like that).

I would also suggest tinkering with the timing settings to see if that helps.

There's also a registry setting that controls how fast the generic serial interface will send data to the hardware. Unfortunatly, it's not configured per-instance and will effect all Generic Serial interfaces. But if you want to mess with it, you can create a registry key in the HKEY_CURRENT_USER\Software\CeBotics\HouseBot\Generic Serial Settings section (you will need to create it) and then create a Inter Char Send Delay DWORD value. The value is the number of milliseconds to delay between each character when sending.

Thanks for the explanation Scott. I'm not tinkerin' with nothing at this point It's working; I'll leave it at that. But it is puzzling that this interface is running at a piddlin' 9600... and sending all of 8 bytes to the hardware. The Arduino, upon receipt of the command string, sends back a short message followed by a 2 byte count-down type of status message. So I'm not sure whether the failure was on the transmission portion (HB->Arduino) or reception (Arduino->HB). Changing the response timeout from 500 to 50 (Arduino->HB) SEEMED to correct the problem, but I also shortened the HB->Arduino command from 12 bytes to 8. so it might have been a transmission issue.

What does the "Inter Char Send Delay" default to, lacking registry entry?

Steve Horn wrote:What does the "Inter Char Send Delay" default to, lacking registry entry?

Sends the entire packet in one batch. If the Inter-Char setting is set, it will send 1 byte/char at a time and delay between each byte/char. It's changes the flow to more of a controlled data stream vs. block. In reality, the OS still streams the data to the device at the rate at which you have the port configured. But this setting allows you to slow it down even more.

Thanks; that helps me to understand what's going on.

8/30 Update: The HW interface to Arduino failed last night, as it had done before. Seems that only HB restart (and PC reboot restores it). I've lowered the interface bit rate to 2400 from 9600 bps and will see if that corrects. Did notice that after closing HB and preparing to kill the process to reboot, decided to reboot w/o killing HB process, since every time I do that the hardware interrupt CPU % shoots up to 80% or so requiring a cold boot (i.e. pull the plug). Without killing the HB process a warm boot is possible and more graceful.
(Not soliciting any replies or new ideas; just using this space to notate what I've tried and discovered.)
9/3 Update: Suspected the 4 port serial card as the source of the "Can't kill HB/HW Interrupts Gobbles CPU cycles" problem, and could not find any later drivers for the card. So I replaced it with new/different brand (Rosewill)/same country of Origin (China). That seems to have corrected the kill HB and HW interrupts issue. Now I can get back to debugging the Arduino serial interface (which is USB not RS232). Progress.

Now I've gotten this one several times on HB startup: "SetCommState()" - appears in the error log and the HB startup window. All serial comms (except as noted with the Arduino issue still under investigation) work ok. Still having to kill HB via Process Explorer most times in order to shut it down. But no longer having the problem with the hardware interrupts.