qnx + usb devices

[TexasTim]

Hi,

We obtained a 6501 and 6008 USB device and would like to run these under the QNX Neutrino operating system.  We realize there is no USB driver available for QNX but hoped to develop our own.

But searching the forum I found a posting that indicates there is no DDK for USB devices. However the rest of the discussion seemed to indicate that one could interface with USB devices via the NI-DAQmx library.

So I took the QNX USB driver development kit and from the sample keyboard USB driver I created one for your devices. Now when my driver is running I can detect your device being plugged in or removed. From doing some USB queries on the device I see it's set to Bulk Transfer mode as opposed to Interrupt mode.

From looking at the documention on the device and reading your forums I understand this to mean that I must now poll your device through my driver in bulk mode. That's simple enough to do, but of course I have no idea what data to send to the device to ask for data nor any idea how to decode anything I might receive. That's the information that I basically need at this point (essentially the protocol the device understands). I have not been able to find that level of information anywhere when I looked through the sample code on the CD-Rom that ships with the device. Is this information available anywhere?

I know there is a library for Neutrino for PCI devices. Can I just use that library to encode/decode the data to be sent to the device? If so, which API calls would I need to use to talk to the 6501 and 6008 device?

Thanks,

Tim Sowden

[Jeremy_C]

As you've noted, in order to communicate with these USB devices under a QNX OS, you would need to write your own driver.  These USB DAQ devices use a messaging communication protocol that is not currenlty available externally.  With that said, can you explain how you are wanting to use these devices?  I assume you will be wanting to implement some AI and DIO functionality.  Regarding the AI, are you wanting to perform single point, finite, or continuous acquisitions?  At what rates?  Will you be wanting to utilize the AO or CTR functionalities?

[TexasTim]

Jeremy,

I believe writing the USB driver part won't be an issue given that I can already 'see' your device and that it seems to be a simple block transfer to send/receive data.

Perhaps a description of what we want to do with the devices would help here:

For the digital I/O we have two types of inputs:

1. Hard switch - one activation of a momentary switch will need to trigger a digital HI (input) that goes on to the USB stream (for that channel) and gets "read" by our computer which will activate the associated function accordingly. For example, I will have a switch labeled XXX ON/OFF and the line will be switched HI for ON. - I have a circuit that will latch the push-button's output so it will act like a toggle switch, therefore, the digital input channel to the device (which is also the input to our system) will remain HI until a subsequent activation of the switch toggles the line LO and it will remain LO for OFF.

2. The second type of device we use is an Optical Encoder. Using the NI test software under Windows (with the C interface that was provided by Version 8.3), we found that we needed to up the read rate to 50 times per second (20mS) since the sample program comes through with a default setting of 1000mS (once per sec. - which would normally suffice for a toggle switch), but when we rotate the Encoder knob fast, you could cause it to "skip" values. This device will use 2 digital "IN" channels for data: 00 // 01 // 11 // 10 // 00 (grey code) OR 00 // 10 // 11 // 01 // 00 based on direction of rotation - which we interpret with our software. The dial for the Encoder also has a momentary push-button built in (depress knob) which we will use as a "center-up" function to set the end device to its center (or neutral) position / value. So this is an additional input that is just for that device. Since that switch is truly a momentary switch, I would probably prefer the default minimum be no greater than 500mS for any given digital IN (perhaps 100mS just for the encoder "reset" push-buttons).

For the analog I/O we have one type of input:

1) For the Analog Channels, we noticed that the NI device could be selected to sample "N" amount of values and then send this "block" of data (at high rates). The main analog device that we use is a joystick (several actually) that will utilize the on-board power supply 5VDC across the joystick potentiometers to give us 0 to 5vdc for the full range of any joystick axis (Our own power supply could be used here as the Analog Channels do have a wider range available - "I", current limitations for inputs being observed). As far as how we want to read this: We need to sense a change immediately without having any of the data being buffered. I assume this means "continuous" (but see the set up information below). If someone moves a joystick, we need to get that data to our system computer immediately. As far as rate, I verified that our control loop rates are 10Hz for any given hydraulic proportional control valve circuit because the valve assemblies themselves can not respond to any given change that would occur faster than that. (i.e. - if you could move the joy stick at a faster rate, the valves couldn't follow it and you'd be in "catch up" mode - you couldn't physically make the vehicle move that fast anyway since you would also be reaching the physical limitation of the thrusters / response. The best setting for the Analog IN (which was not available for all channels with the Test Software) was "INPUT CONFIGURATION - RSE" ; "MODE - ON-DEMAND" (which I took to mean Real Time since the Samples and Rate value boxes are "greyed out" in that mode) and I had my values for the channel set to -0.2V for MIN and 5.10V for MAX. I interpret this to mean the input was set for a single-ended device with an approximate output of 0 to 5 VDC and I opened up the bounds a little to catch any overshoots. I set their "virtual O-Scope to NO Auto-Scale and the input looks real good. The "CONTINUOUS" setting in their software actually activates the setting boxes for amount of samples and rate - so I think the "ON-DEMAND" setting is probably effectively "read - and send - immediately", which is what we need.

I hope this helps describe what we want to use the devices for.

So the question remains about getting the protocol to program the device for these types of aquisition settings and how to interpret what we get back from the device.

Thanks,

Tim

[rob.dotson]

I know this has been years, but was there ever a resolution to this? I'm trying to do the same thing for the NI USB-6221, but I can't seem to find any information, two years later...

[Tom_W_[DE]]

Hi Rob-

I responded to you directly via email.  The situation is mostly the same as when Jeremy responded, but we do have a few options now for helping with requests for this material.  

Thanks-

Message Edited by Tom W [DE] on 01-08-2009 03:54 PM

[ksart]

I too need to write a QNX driver and I went to the MHDDK link and could not find protocol information for the USB 6259 ...is this available somewhere.  

[WiseMan2015]

Could you please send me a copy of the keyboard source code driver example.

Thanks

[TexasTim]

Wiseman,

The keyboard source code example comes with the QNX DDK development kit. If you get that kit from QNX's website you'll have a copy of it. Of  course that only works with a generic USB keyboard.

If you want the USB code for the National Instruments device you'll have to download it here. Then you have to convert that from Linux format to QNX.

Tim

[jspring@berkeley]

Hi Tim:

I know this is like a decade later, but if you're still there-- did you ever get anything working? 

Thanks,

John

[neelay.junnarkar]

Hello,

I'm also interested in this. The MHDDK page (https://www.ni.com/en/support/documentation/supplemental/18/measurement-hardware-driver-development-...) now  lists the "NI 62xx M Series MIO" as supported. The USB-6221 falls under this. Does this mean that the MHDDK supports the USB-6221 and other USB DAQs in this series? If so, would I be able to use the MHDDK to program the DAQ for reading on AI and writing on AO?

Thanks,
Neelay