Compact rio not being able to use C

I may sound like an idiot here but awhile back a person from NI came to my team and told us that the compact RIO can’t use C programing. I was not at that meeting and want to know for sure if this is true. Can you guys give me and other sources than FIRST and NI, because they have so far been non-conclusive. It would be great if someone had a link to a place where this was announced, so i can show my team.
Thank You.

I suggest you look around. It has been clearly stated a number of times that the compactrio WILL be supporting C and that WPI will be handling the C library coding to keep it on equal footing with what NI releases for Labview.

Thank you i thought so i just need a way to prove it to my team because this guy was a pretty smooth talker and has them all convinced.
this is good news for me thanks for the fast reply.

On the WPI FIRST page regarding the new control system which is linked from the FIRST website it says:

The cRIO from National Instruments can be programmed in LabVIEW or C.

National Instruments has not yet released anything for C with the Compact Rio to the general public. We are one of the guinea pigs.

It’s very likely the person you spoke to is not aware of the development of the FIRST controller and the C interface.

Here is the NI press release, which mentions C programming: http://digital.ni.com/worldwide/bwcontent.nsf/web/all/F70C10117567BBF18625742B00737DF5

Does anyone know if we can use EasyC with the new controller? Forgive me if that’s a stupid question, I’m no programmer. The last thing I programmed was an Apple 2 using Basic.

No, currently there is no plan for EasyC or any program like it to be available for the new controller. However, if you’re used to using EasyC, using LabVIEW might not be too difficult since LabVIEW is a graphical programming environment, where you place blocks on a block diagram and wire them together.

I haven’t heard anything about EasyC being adapted to be used with the new controller, but I expect someone to release a comparable IDE for the new system.

Thanks.

Intelitek hasn’t given an official statement regarding easyC, (imho) it sounds like they are either working on it, or they are not. So I wouldn’t rule it out (just quite yet.)

My $.02
Jacob

From my understanding, the cRIO would be programmable in C++. Is this still the case? I remember quite a buzz about finally being able to use C++ as opposed to C.

I heard that to, or was that dealing with using C++ inside of labview.

From what I remember from the mentor presentation in Atlanta, the compiler that will be used is GCC (with an IDE provided by Wind River). So since C++ is mostly a superset of C, if the base code is provided in C it will compile in C++ as well. (I suppose this implies that you can also write a module or two in Fortran, Objective C, Ada, etc. if you really want.)

I realize the base code will compile in C++ if you can compile in C. However, I’m looking forward to using the features presented in C++ that aren’t in C such as being able to use Object-Oriented Programming techniques and templates. My question is: will we be able to write/compile code in C++? I thought that this was the case.

I haven’t done much work with Compact RIO, but can you not use Code Interface Nodes with them?

If the base code will compile and run in C++, I don’t see why you wouldn’t be able to use OOP and templates; it all just crunches down to machine code in the end.

If I were to speculate, I would guess is that the base functionality provided by FIRST will all be in C, but teams will be free to write their extraneous code in C++ and just interface it with the C base code.

CINs are ancient, and new platforms like cRIO do support the Call Library Function node, which will call vxworks .out files.

Greg McKaskle

Some of the cutting edge C++ stuff may be a bit rough, but the LabVIEW code base contains plenty of C++, and it runs there. As usual, bringing in arbitrary C++ code can run into rough spots when deciding whose STL implementation to use, or doing lots static initializer stuff, etc. But the short answer is, that it is a C and C++ platform via Wind River tools, and a LabVIEW platform via NI tools.

Greg McKaskle

There’s nothing wrong with the CINs being ancient. They still work…and allow you to access compiled C and C++ code. I haven’t used a Call Library Node. Most of the code I use at work was already written for use with CINs.

Correct. There isn’t anything wrong with being ancient, but being ancient is one of the reasons they aren’t supported on new platforms. To give a bit of history, CINs were invented when LV was still on the Mac, and there wasn’t a good choice for dynamically called binary code – no DLL-like entity. Since they were being constructed, a number of other bells and whistles were added to them.

Around six years later, when CodeFragments on Mac, and DLLs on Windows existed, the CallLibrary node was added. In some ways it is superior to CINs, in other ways, it was a bit lacking since it was defined industry-wide, and not inside the LV team. In the fifteen years or so that have passed since then, both have been maintained and reworked. In the next release, NI will no longer ship any VIs containing CINs. Over the year, as code is touched for some other reason, it has been moved to CallLib nodes, but we still support them because customers have written them, and don’t necessarily want to spend the time taking their C code to a new library format. If it works, why change it.

On the other hand, new platforms, like cRIO can’t use existing CINs. They require the C code to be recompiled for a new OS anyway. This will require reworking the make file, the header includes, dealing with little nit picky C stuff that was marginally compatible. So while doing that, we think it is better to move from CIN libs to .outs, .DLLs, .frameworks, .libs, or whatever the platform preference is for shared binary code.

And that is the state the cRIO is in. It supports external binary code written by you, by the OS vendor, by third parties, etc. It does so in a standard way rather than the twenty-x year old proprietary way that LV invented.

That was why I called them ancient, and that is why the cRIO doesn’t support CINs. Ancient doesn’t necessarily mean bad, but ancient things do fall out of use, otherwise I’d be tapping this out in morse code or writing it in Latin.

Greg McKaskle