January 31 this year I posted a request for information and have received absolutely no response. All I asked for is a little bit more DOCUMENTATION on your product. I was very specific and limited in my request. The lack of responsiveness makes me question the advisability of including your product in my product even though your product is physically a very good one.
Why no response to such a simple request? Can you at least tell me why there was no response?
Here is the text of my post. Note particularly the last sentence.
Quote
My application is such that I cannot use your standard SDK's and must develop a different interface technology. I have successfully created an interface module by adapting the code in your HID examples. I have added the ability to turn on and off the LED, set the axis enable state, and to to be able choose either event driven or polled data access.
The LED control function was achieved by extensive reading of many pages on the USB web site and in the Windows DDK documentation. The axes enable state function was achieved by good old fashion hacking and a lot of luck.
The functionality I have implemented so far is sufficient for my purpose but I am interested in possibly using some of the other six undefined and undocumented Report ID's. To that end, it would really be nice if you provided documentation for your devices so that we could know how to program them rather than using a guess by golly approach. In particular, the documentation of your vendor specific User Page ff00 capabilities for the SpaceNavigator would be greatly appreciated.
Unquote
No response to HID question in 9 months
Moderator: Moderators
Hello lgriffith,
Sorry for not responding to your initial request.
You certainly must understand that some packets are for internal usage only (for instance for use during the manufacturing process). Some are not documented because we don't want you using them--we may very well change them in the future as we need to. This is a disadvantage of USB, where all private communication must be done over an essentially open channel.
If your company wants to OEM our hardware products, please make a separate request for internal hardware details to our World Wide OEM manager.
One packet that you didn't mention though, could be useful for you. I believe this is documented elsewhere on the Developer's Forum.
ID 7 is the rezero command. That tells the device to take its current position as its "rest" position. If the device is drifting for some reason, this packet will stop it. OTOH, if you are pushing on the device when you issue this command, it will constantly drift as soon as it returns to its mechanical center. This is a two byte packet {7,0}.
Jim
3Dx Software Development
Sorry for not responding to your initial request.
You certainly must understand that some packets are for internal usage only (for instance for use during the manufacturing process). Some are not documented because we don't want you using them--we may very well change them in the future as we need to. This is a disadvantage of USB, where all private communication must be done over an essentially open channel.
If your company wants to OEM our hardware products, please make a separate request for internal hardware details to our World Wide OEM manager.
One packet that you didn't mention though, could be useful for you. I believe this is documented elsewhere on the Developer's Forum.
ID 7 is the rezero command. That tells the device to take its current position as its "rest" position. If the device is drifting for some reason, this packet will stop it. OTOH, if you are pushing on the device when you issue this command, it will constantly drift as soon as it returns to its mechanical center. This is a two byte packet {7,0}.
Jim
3Dx Software Development
Thanks for responding - at long last.
I will have to check but I think I am already using the command you suggest. After all, it has been over nine months since I developed the HID interface software. The details get a bit foggy after while. Its the function of documentation to facilitate refreshing one's memory.
I would suggest that the customer should be the one to decide what to use or not to use. Supply the information with warnings about what might be changed without notice. However, leave it up to the customer to make the decision AND to take the risk or not.
YOU must understand that you cannot possibly guess all the possible used there might be for your product. By unnecessarily restricting access to information you are very likely limiting your market. Its your right to do so, but is it wise?
I will have to check but I think I am already using the command you suggest. After all, it has been over nine months since I developed the HID interface software. The details get a bit foggy after while. Its the function of documentation to facilitate refreshing one's memory.
I would suggest that the customer should be the one to decide what to use or not to use. Supply the information with warnings about what might be changed without notice. However, leave it up to the customer to make the decision AND to take the risk or not.
YOU must understand that you cannot possibly guess all the possible used there might be for your product. By unnecessarily restricting access to information you are very likely limiting your market. Its your right to do so, but is it wise?