USB RAW Communication with USB-6366

[EricLarsen]

I've got a bit of an unusual situation here.  A customer has an existing cRIO-9036 running real time Linux.  They also have a USB-6366 acquiring some high speed signals for another system.  They would like to interface the high speed signals to the crio system.  They've asked if it's possible to connect the USB-6366 to the cRio.  

The crio system recognizes the USB-6366 as a USB RAW device.  So the question is it possible to control the USB-6366 using RAW communication?  I've got no experience in this area and haven't been able to find any documentation on this.  The application is pretty simple, just wait for a trigger, store some analog data, then download it to the crio for processing.

Ultimately the correct solution is probably to buy a couple NI-9775 modules, but for bureaucratic reasons this isn't possible now.

 

 

[JKSH]

According to http://digital.ni.com/public.nsf/allkb/79CB44F7E228AED88625756E00445151?OpenDocument, "Compact RIO systems have a FPGA in the backplane which prevents DAQmx from being used"

But just to be sure, I'd ask NI via official channels to get a definitive answer

Edited March 8, 2017 by JKSH

[MarkCG]

I wouldn't bother. You would have to reverse-engineer how DAQmx communicates to that device and then implement that yourself. Explain to them how much of your time this would take and what it would cost at your hourly rate vs buying the module

[smithd]

6 hours ago, EricLarsen said:

So the question is it possible to control the USB-6366 using RAW communication?

Yes, but as Mark pointed out I'm pretty sure you'd have to reverse engineer the interface :/

The funny part about this is that several of NI's competitors sell usb daq and oscope systems with drivers you can talk to with visa. As long as you dont pick one that needs a specific dll you should be able to get it to work on a crio.

[ShaunR]

It sounds like the cRIO doesn't have the device profile. I'm guessing here, but on Windows we use MAX to create a profile for an unknown device or tell MAX what the device is using *.cfg files for that device. IIRC there is a NI DAQ Configuration Utility for Linux targets where *.cfg files can be imported. Maybe have a hunt around the forums for more information about the utility, because raw USB is a nightmare.

[Rolf Kalbermatter]

On 3/8/2017 at 2:21 AM, JKSH said:

"Compact RIO systems have a FPGA in the backplane which prevents DAQmx from being used"

That sounds like a pretty lame excuse. The FPGA has very little to do with the fact that DAQmx wouldn't be portable to cRIO and in fact it is available on various cRIO systems nowadays. Please note that the LabVIEW version that KB article refers to is for version 7.1 and shows a DAQmx version 9.8 dialog while the current DAQmx version is 16.0.

The problem is that the USB-DAQ systems are not supported on DAQmx for cRIO systems. The reason for that are probably manifold but the fact that every type of subdriver in DAQmx is a considerable effort and that cRIO systems have alternative DAQ options already plays most likely an important role.

Trying to get this working yourself by communicating on USB Raw level is an exercise in vain. First you would need to get the actual USB protocol description for the USB-6366. With the exception of a few very simple low cost devices, NI never has published protocol specs for those devices. There was a tutorial like article in the past, that explained the creation of an USB Raw interface driver in LabVIEW with one of the USB-900x devices, but I can't find that right now. However those are low speed and very simple devices that likely do not use any features like USB interrupt pipes or any other modes than bulk transfers. With the USB-6366 this is very likely different, as you can't support continuous and reliable multi-megasample per second transfers through a simple bulk transfer pipe. You typically have to use (multiple) isochronous endpoints for that and likely some interrupt pipe endpoints too, for the signaling and protocol handshake.

This document points out that you would not need to do the inf driver wizard magic for non-Windows targets. On Mac it just works if the device is not claimed by a driver already and on Linux you have to make sure that it gets mounted as an usbfs device. This should also apply for the Linux RT cRIO targets. If the cRIO are however one of the older VxWorks or even Pharlap ETS based devices you can anyhow forget about it immediately. They don't support USB Raw communication at all! The only way to get a custom USB device working on them is to actually write a custom USB kernel driver for those systems, which requires the according development system for Pharlap ETS or VxWorks, which is a major investment on its own, not even accounting for the trouble of getting acquainted with development of kernel device drivers on those highly specialized OSes. 

But inf driver wizard or not, the real work only starts after that. You have to use VISA functions to write the correctly formatted data packets to the different communication endpoints in the device and receive the answers from it. This is very tedious low level work for any non-trivial USB device, even if you happen to have a complete bit for bit protocol description for it. It is a sure way for insanity, to try to do without such a protocol description. These protocols are usually not just some text commands that you send to the device like with traditional GPIB, or RS-232 devices. The exception to that are USBTMC devices which implement a higher level service that allows to send SCPI and IEEE-488.2 compatible string commands. But for USBTMC devices you don't need to do anything special in terms of VISA communication. You simply address them with the USB::INSTR resource name instead of USB::RAW, and then communicate with them like any other SCPI/IEEE488.2 like device. But there is no reason for NI to implement USBTMC for their DAQ devices and consequently they haven't done so. This saves a very complex command interpreter in the device and therefore makes it possible to use a smaller and cheaper embedded processor in the device. Also by using a fully binary protocol, the USB bandwidth is better utilized.

Edited March 9, 2017 by rolfk

[smarlow]

Since they are already acquiring signals with the USB-6366 DAQmx device, I'll assume they have it connected to a PC.  What is the motivation for disconnecting the USB-6366 from the computer and connecting it to the cRIO?  Are there space limitations?  Are they trying to fit everything in a box? If not, why not just transfer the data from the USB DAQ device to the cRIO via a TCP connection?  What is it you are really trying to do?  Are you doing calculations and/or control based on data collected from both devices? Could you not also transfer the cRIO data to the PC?  I guess the question is really why are you trying to get rid of the PC?  Another option that might be possible, if there are space considerations, is to buy a small PC like an Intel NUC.  That could run the code collecting data from the USB DAQ, and transfer it to the cRIO via a TCP connection.  Since the USB device is non-deterministic anyway, you are not losing anything except a little more latency time added to repackage the data and send it out over the TCP connection.  All of these options sound complicated versus just buying the cRIO modules needed to replace the USB device.  As the others have stated, trying to communicate via USB raw is a big waste of time, since it would cost far more than just replacing the USB hardware.

Edited March 10, 2017 by smarlow
typo