Making USB-8451 work with PXI running LabVIEW RT / Phar Lap ETS

[codcoder 1]

Hi,

I have a problem here. Hope I can get some help for a solution.

The task at-hand is to use an NI USB-8451 to communicate with a device over I2C. This would have been trivial if it wasn’t for the fact that the USB-8451 is connected to a PXI controller running LabVIEW Real-Time OS (Phar Lap ETS) and not a Windows PC.

I haven’t chosen the hardware combination personally and the person who did just assumed they would work together. And I did too… I mean, it's NI's eco system! Just download the NI-845x Driver Software from NI’s webpage, install it on my PC and then install whatever software needed on the controller through MAX. Easy right?

But no. It wasn't that easy.

So I wonder:

(1) Has anyone had any success controlling the NI USB-8451 from anything but a Windows PC? And if so… how?? The PXI system finds the USB-8451 and lists is as a USB VISA raw device but the supplied vi’s/drivers cannot be executed on the controller.

(2) Since what I want to do is actually very little (just writing a couple of bytes once to the I2C device) I have started to toying with the idea of recording the USB traffic from the Windows laptop somehow via Wireshark and then replaying it on the PXI system… has anyone had any success doing something like that?

(3) And finally. If it is impossible to get the USB-8451 to work with my PXI system, is there some other I2C hardware that is known to do? I’m getting the impression that NI only has this USB device apart from implementing the I2C protocol on a dedicated FPGA and that seems a little too much.

Sorry for the long post. Getting a little desperate here. Deadline approaching.

I'm running LabVIEW 2019 SP1 by the way and the controller is a PXIe-8821 if that makes any difference.

BR, E

[crossrulz 90]

At this point, I would probably go a slightly different route.  You could get an Arduino or Raspberry and program them to do the I2C communications for you.  In the RT system, you can just communicate the data through a serial port.  Another option I have been tempted to go with is to use a SC18IM700IPW, which is a I2C-UART chip.  Again, you just have to use a serial port to talk to it.  But this would be more hardware design than the other option.

[hooovahh 768]

Adding to crossrulz suggestion.  If you do want simple I2C or SPI, using an Arduino is a great solution in LabVIEW.  NI has their LINX toolkit, which downloads a known set of firmware to the Arduino, and then in LabVIEW you have the LINX palette which basically tells the microcontroller to execute some set of steps.  These commands are just serial commands, and when plugged into USB should appear as a normal VISA device in LabVIEW.  I don't have a pharlap system to test with but with other remote devices I've used they just get enumerated when they are plugged in.

I personally have not used pharlap much and am unaware of the difficulties getting that hardware working on it.

[codcoder 1]

Thanks for quick answers.

I was afraid changing hardware would be the answer. Doing that isn't that easy either as the hardware configuration is quite fixed at the moment.

My current "temporary" solution is to use a Windows PC connected directly to the USB device running a looped LabVIEW *.vi which constantly writes i2c to the device every second or so. This works.

I will look into other neater solutions as soon as I get the time. I promise to post an update here if I figure out anything useful.

[codcoder 1]

For posterity: I've been in contact with NI Technical Support who confirms that the USB-8451 isn't designed to work with PXI Real Time controllers.

[Gribo 20]

You can reverse engineer the protocol with NI-trace. It is quite trivial.

[codcoder 1]

On 3/5/2021 at 7:24 PM, Gribo said:

You can reverse engineer the protocol with NI-trace. It is quite trivial.

Do you have any examples about this you can share? Becuase I tried using NI-Trace -- and perhaps it's about my lack of knowledge about the tool -- but to my understadning what was logged was nothing but the "high level" writes to property nodes and sub-vi's which I did in my top-level vi's. There were no information about the underlying USB communication.

Edited March 8 by codcoder

[Gribo 20]

I'll give it a shot later today. Might require Wireshark.

[Rolf Kalbermatter 506]

On 3/8/2021 at 1:23 PM, Gribo said:

I'll give it a shot later today. Might require Wireshark.

Almost certainly. This device does almost certainly not use a standard USB device class and that means you will have to program on NI-VISA USB Raw to emulate the commands that the native Windows driver sends and receives from the device using directly USB device driver calls. Possible? Yes but not easy and pretty for sure. If it wasn't such a pain to use VISA USB Raw on modern OSes, I would have long ago released a driver for the FTDI chips using pure VISA calls.

Edited March 11 by Rolf Kalbermatter