mikeobrien
WaitTimeOut persists
If a WaitTimeOut is triggered when reading a report then all subsequent attempts always result in a WaitTimeOut
example pseudo code:
device.OpenDevice(DeviceMode.Overlapped, DeviceMode.Overlapped, ShareMode.ShareRead | ShareMode.ShareWrite);
device.WriteReport(replyWithDataReport); HidReport rpt1 = device.ReadReport(1000); // rpt1 read status is Success
device.WriteReport(noReplyReport); HidReport rpt2 = device.ReadReport(1000); // rpt2 read status is WaitTimeOut
device.WriteReport(replyWithDataReport); HidReport rpt3 = device.ReadReport(1000); // rpt3 read status is WaitTimeOut
I find this very perplexing, because in your example you open the device with DeviceMode.NonOverlapped, which should cause HidLibrary to ignore the timeout and return with read status Success every time. The only way I could explain this is if the device object had been opened earlier with DeviceMode.Overlapped. It would have to be opened that way explicitly, as the default is NonOverlapped.
Now, assuming this were the case, I would think there's an issue between Windows and the device itself. If this really is the first time that device is opened, then I can't follow a code path that would set status = HidDeviceData.ReadStatus.WaitTimedOut in that configuration.
Are you running with the latest version of HidLibrary from git?
I find this very perplexing, because in your example you open the device with DeviceMode.NonOverlapped
mistake in my example, I am opening the device with Overlapped
Are you running with the latest version of HidLibrary from git?
yes, version 3.2.37
I have a work around by closing and reopening the device anytime the read status is not success, seems to fix my issue but its not ideal:
HidReport report = device.ReadReport(1000); if (report.ReadStatus != HidDeviceData.ReadStatus.Success) { device.CloseDevice(); device.OpenDevice(DeviceMode.Overlapped, DeviceMode.Overlapped, ShareMode.ShareWrite | ShareMode.ShareRead); }
This sounds like a problem with the device then. HidLibrary calls ReadFile with a new event handle each time, so it's not like the HidDevice object is getting stuck in a bad state. The device is timing out at the operating system level. Closing the device handle and re-opening helps Windows get it unstuck, but yeah, that's not ideal.
Do you have access to the device code? There might be a bug on that side.
I dont have the device code, but I can contact the developer.
I'm not clear on how this can be a bug on the device end. Are you saying it is the devices responsibility to handle the timeout? Can you explain in more detail how this works? Thanks!
From: Austin Mullins [email protected] Sent: Tuesday, June 28, 2016 8:06:08 PM To: mikeobrien/HidLibrary Cc: jvdub22; Author Subject: Re: [mikeobrien/HidLibrary] WaitTimeOut persists (#67)
This sounds like a problem with the device then. HidLibrary calls ReadFile with a new event handle each time, so it's not like the HidDevice object is getting stuck in a bad state. The device is timing out at the operating system level. Closing the device handle and re-opening helps Windows get it unstuck, but yeah, that's not ideal.
Do you have access to the device code? There might be a bug on that side.
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mikeobrien/HidLibrary/issues/67#issuecomment-229244645, or mute the threadhttps://github.com/notifications/unsubscribe/AAuIOKaGGpNF0-ExwI7z7IjTxHGdyFBZks5qQeEggaJpZM4JAhWF.
I'm saying that the device is not responding to the host in time, yes.
I was working with a custom device a few years ago where the firmware developer was trying to implement a double-buffered I/O port using USB HID. It didn't always flush correctly, so they changed the firmware to always output some dummy buffers after the actual data was finished. My application would then get all of the actual data, but sometimes the buffers arrived out of order. While debugging this, I switched from HidLibrary to HIDAPI. Of course, the problem persisted because it was the device, not the library, causing the issue.