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?
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
Implementing a Custom Digital Interface with Intelligent DAQ
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.
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.
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: 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.
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.
How were you able to communciate with the FPGA code from your .out?
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.
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.