NI8452 on an Rt machine

[Bobo083]

Hello,

I am working on a application that use NI8452 for reading and controlling an I2C bus but in the same time i need to aquire analog data from an Crio (RT machine).

I was trying to deploy the up develop for NI8452 on the real target but i get an error which say that some library must to be install on the real target.

The problem is that NI8452 driver  is only Windows.

So my question is how i can use in the same time an app develop for my Ni8452 and in the same time to get measurement through  an RT machine.

Thanks!

[santo_13]

AFAIK, NI-8452 does not have support for RT

[Bobo083]

Right , I know that before to post but i think i can use my NI8452 Vi running under Windows and the i got a second Vi which does the analog acquisition which i can run it on the RT

I would like an example how to stream date acquired from RT VI to the vi running under  Windows  running under Windows

[santo_13]

Let me rephrase what I understand,

1. You've application A that streams some data from cRIO (RT)
2. You've application B that controls some devices using USB-8452
3. Now you want an example to combine both A and B into a single application C that will run only on Windows?

If above statements are correct, then your topic is completely misleading as if you want to use 8452 directly on RT system.

[rolfk · Accepted solution]

I think your point 3) is an assumption that I can’t quite reac into the OP’s later explanations (but are definitely how I understood the initial request too). If that assumption is real the answer is indeed: you can’t!

However you can have an application on the cRIO and one on the PC and have them communicate together. One way could be through VI server, another through network streams and the third through raw TCP/IP data streams. For each of them there are examples that ship with LabVIEW, not exactly as in this setup but definitely as communication between two separate VIs. To put the two sides in two separate executables is simply an exercise in a little software engineering.

[Bobo083]

Now i understand that Ni8452 does't have support for RT so i want that my application B which running under RT to stream to application A which runs under Windows.

Application A already got the code for Ni8452 so i want to add code that makes possible to get the stream data from B

Is that possible?

Thanks

[Bobo083]

So my B app on the RT collects the state of some switches into a boolean array and count how many tine a close the switch into a numeric array + reads 16 channels analog voltage.

So you say that with network streaming i can transfer data from B (RT) and then log then on A application (windows). Is that correct?

[Bob_Schor]

---

@Bobo083 wrote:

So you say that with network streaming i can transfer data from B (RT) and then log then on A application (windows). Is that correct?

---

Yes, that is certainly possible.  The question you need to ask is how closely do you need to synchronize the two tasks (or, really, the three tasks) -- interacting with the User, which is the responsibility of the PC running LabVIEW, doing something using an NI-8452 to communicate with some hardware over I²C (not sure how this relates, time-wise, to the other tasks), and "collecting the state of some switches and counting switch closures + reading 16 channels of A/D at some rate".

If your data rates are "reasonable" (a few kHz instead of many MHz), your RT hardware reasonably robust, and if the letters F, P, A, and G (slightly permuted) don't throw you into a panic, I'd say you should consider a design that uses the PC for the User Interface and File I/O, and uses a cRIO or similar robust RT hardware for both the I²C and DAQ tasks.  Those mysterious letters, slightly permuted, might well be able to handle I²C communication, and should also be able to do conventional DAQ through plug-in modules.

[Confession -- I've not done a lot with cRIOs, but have used sbRIOs and myRIOs to handle DAQ tasks and SPI communication, controlling multiple channels of custom boards with A/D, D/A, and DIO (SPI-driven) chips, with timings in the tenths of millisecond range.  I'm assuming that a cRIO with FP-whatever support, is at least as capable ...].

Bob Schor 

[rolfk]

---

@Bob_Schor wrote:

---

---

Those mysterious letters, slightly permuted, might well be able to handle I²C communication, and should also be able to do conventional DAQ through plug-in modules.

---

Make the "might" a "sure can". NI even has example I2C and SPI libraries for implementing these protocols on FPGA. You should definitely not be afraid from some boolean arithmetic logic and have a little more than a basic understanding about digital circuit design but it is also not exactly rocket science that you can only handle after having studied for 5 years.