Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Access to 9870 ports from VxWorks

We've purchased a NI-9870 module with the idea that it could be used to communicate with a custom sensor through the OS on the controller (i.e., from a shared library). It now appears that these additional serial ports are not available to the OS. Is this correct, and if so, is it possible to create a LV interface to allow the .out to communicate with the additional ports?

 

I guess it's not a huge surprise to me at this point that the additional serial ports are not visible to the OS on the controller. Is there a technique to get around this?

 

Chris

0 Kudos
Message 1 of 10
(5,283 Views)

Hello Chris,

 

Your new serial ports will not show up to the OS as COM ports, like one would expect them to in Windows; you will have to program this functionality on the FPGA.

 

The following links may provide some useful information for your project:

 

RS-232 Interface using LabVIEW FPGA module

     http://zone.ni.com/devzone/cda/epd/p/id/2164

 

Implementing a Custom Digital Interface with Intelligent DAQ

     http://zone.ni.com/devzone/cda/tut/p/id/3477

0 Kudos
Message 2 of 10
(5,264 Views)

Thanks for taking the time to respond. It doesn't look like I made myself clear. In this case, I would like to avoid duplicating the effort required to write the serial interface to our sensor. We already have source code that can be compiled to do that (for example in Windows or Linux, etc.). We are currently evaluating whether it can be ported to VxWorks (we have experience writing code for VxWorks that we can call from LabVIEW exe's on the crio controller). If it is possible to port the code, it doesn't look like it will be difficult to utilize the onboard serial port on the controller. What I would like to explore is the possibility of creating a labview interface to the additional serial ports added through the 9870 that the non-labview library running on the controller could access.

 

My current thought is to have a few functions added or exposed from the library so that I can control all of the communication from my labview program. I can configure the port myself, and then call the library and basically work as an intermediary, letting the library give me the bytes it wants written, and telling me how many bytes to read back. I can then just pass that information into the library for interpretation, or even just call some functions to interpret them from within LV. The only consideration in this scenario seems to be that the library would not be able to initiate communication with the LV app, or the port. If that is required, I could deterministically poll the library just to check to see if it had anything to say..

 

These are just the ideas bouncing around my head right now. It almost seems like there could be a scan engine type of approach for dealing with the additional serial ports that a "driver" could deal with to talk to them directly from vxworks.

 

 

0 Kudos
Message 3 of 10
(5,253 Views)

Hello Chris,

 

What you are discussing here sounds like it will work, but may be a bit cumbersome.  Perhaps, it would make sense to partially implement some of the glue code for the sensors in LabVIEW but call your library for any of the more invovled (and difficult to re-implement) logic.  I don't know the details of what your library does so I can't say for sure, but it may be worth considering a hybrid approach.

 

Another option that I think could work quite well for you is a new feature called the C Host Interface.  Essentially, this is a way for custom c code to interface with the FPGA.  What you can do is create an FPGA bitfile that implements the serial port for the 9870 and communicate directly with the bitfile from your C code.  With this approach you don't have to call your library from LabVIEW in order to send/receive data. 

 

The C Host Interface is currently an NILabs release and is missing support for DMA and Interrupts, but you should be able to at least prototype your solution.

Message Edited by Support on 05-26-2009 09:17 AM
0 Kudos
Message 4 of 10
(5,242 Views)

I've definitely considered rewriting all or part of the code in the library, but there are benefits to having a single library to support. It's still on the table. The C Host Interface is intriguing and would theoretically simplify some of the work required to get this going. I'm curious, does it prevent you from interfacing with the FPGA from LabVIEW apps on the controller, or can they both communicate in parallel? A simple example specific to my problem would be loop on the FPGA solely responsible for serial comms, and then other loops responsible for acquiring data from other modules and possibly inserting it into one or more DMA's. In this example, the C code would only interface with the serial loop, and labview code would be responsible for handling the rest..

 

Chris
0 Kudos
Message 5 of 10
(5,239 Views)

Chris:  I was one of the first users of serial on cRIO using the 9870 (and it's predecessor beta module) and the good thing about serial on cRIO / FPGA is that you can have multiple parallel loops running on FPGA, each dedicated to a serial or CAN port with multiple processes accessing (or referencing) a single port (be sure to implement some traffic control). 

 

The main reason I am responding to this discussion thread is that I notice in your note that you want to use a shared library with VxWorks.  Are you aware that .dlls have to be recompiled to .out  files to be used in VxWorks?  I'm not familiar with NIs C host interface, but I was able to get Simulink dlls running on cRIO FPGA (by recompiling into .out files) and they were able to access the serial ports along with CAN and analog I/O, so any questions in those areas are fair game. Whether you are using MATLAB Simulink or not, read the instructions at http://zone.ni.com/devzone/cda/tut/p/id/5694 for help in recompiling a dll into a .out file.  If your dlls were made in Simulink, use the plug in for Simulink provided with the Simulation Interface Toolkit to directly build as a .out file.

 

Bill

0 Kudos
Message 6 of 10
(5,234 Views)

Chris,

 

I'll get you an answer on that.  I suspect it would work, especially when the feature ships, but without trying it or talking to some people I can't say for sure.

 

Bill,

 

How were you able to communciate with the FPGA code from your .out?

0 Kudos
Message 7 of 10
(5,230 Views)

Bill, thanks for getting involved in the discussion. This is the first time I've worked with the 9870, but I have been coding for the crio's for a little while. We have successfully compiled homegrown c code to .out's, and we have just recently started using the SIT to use simulink models on RT controllers. We also have used emlc with RTW and embedded coder to convert m-code to .out's successfully.

 

The thing you said that caught my attention was that you mentioned using compiled simulink models with cRIO to access the serial ports. I'm interrpreting a little because as far as I understand, you can not compile the model to the FPGA. The compiled model is a shared library available to the RT controller running vxworks. If you are using SIT, you essentially get a wrapper vi (I haven't used SIT myself, so excuse me if I misunderstand a little) that is built to interact with the .out. Then you can write LV code to interact with the serial ports on a 9870 and communicate information back to the .out if necessary.

 

If what I just said is way off base let me know. I am encouraged that you said you could access the serial ports from the .out file, but I am confused how that would work. Also, we need to be clear to distinguish the serial ports on the 9870 and the controller, because there seems to be a big difference in how these are accessed. Bottom line, our library was not made in simulink, but if it's possible to access the ports on the 9870 from a simulink model converted to C and compiled with RTW, then we can do it as well. We just need to figure out how.

 

Thanks,

Chris 

0 Kudos
Message 8 of 10
(5,226 Views)
Yeah, you got me there.  I didn't mean to imply that the Simulink or .out read or wrote to the fpga directly, but in hindsight it sure looks like that was what I said.  My excuse is when I responded to the discussion was to emphasize the .dll to.out conversion methods and requirement.  Of course, the only ways I read or wrote from or to the FPGA was either through DMA FIFOs or queues (by reference).  And of course since I answered on my employer's time (I'm not supposed to get "distracted" on the job) it was a hasty and ill thought out reply.  Sorry.  I was just trying to keep you form wasting a lot of time discovering something that isn't well documented or at least not common knowledge...
0 Kudos
Message 9 of 10
(5,208 Views)

Hello Chris,

 

I did some asking around and yes, what you've described should work just fine.

 

You'll just need to make sure that open is called first from LabVIEW.  Later on if you attempt to open the same bitfile from the .out (same signature) it should open the reference and give you access to controls and indicators.

 

Let me know if you have any more questions.

 

Sebastian

 

 

0 Kudos
Message 10 of 10
(5,193 Views)