10 replies to this topic

[Michael Aivaliotis]

I guess I've been out of touch. When did this come out?

http://sine.ni.com/n...g/en/nid/209015

[Cat]

Too bad they don't have something that goes the other way.

I wonder how well this actually works.

[asbo]

A least a month or two, I remember seeing an e-mail go by, I think. I'd love to see how this works its magic as well. Perhaps I'll take it for a spin tonight and see how well it crosses over.

[ShaunR]

Too bad they don't have something that goes the other way.

I wonder how well this actually works.

I assume its an offshoot from their embedded tool kits (you can't run LV on for example an ARM processor). where you write stuff in LV and it generates the C code which you then have to compile using a C compiler. The other way round would be awesome.

[mje]

They had a little booth at NI Week and it looked pretty slick. Beyond that I haven't had time to look into it. The fellow at the booth mentioned it was new to 2010.

[Bobillier]

Have a look here

http://zone.ni.com/d.../tut/p/id/11784

[rolfk]

Too bad they don't have something that goes the other way.

Well you can convert C algorithmes quite easily into the formula node as that one supports a subset of C. For whole C
programs there is simply no way to translate that in a meaningful way into a LabVIEW program by automatic and in fact
even translation by humans is mostly an exercise in vain as the runtime concepts are quite different. And if a human
can't do it how could you come up with an algorithm that does it automatically. I'm not saying that you can't rewrite a C
program in LabVIEW but that is not translation but simply reading specs (here from the C program) and writing a
LabVIEW program from scratch. C is in no way as formal and strict as more modern design paradigmas such as UML etc.
and I haven't seen LabVIEW code generators that can translate such design documents readily into LabVIEW VIs.

I wonder how well this actually works.

If it is indeed simply the code generation part from the embedded Toolkit (and I'm almost 100% sure it is), then all I can
say is: The code generation works but it ain't pretty to look at. Personally I don't see much use in generating simply C code.
The embedded Toolkit makes some sense when used with a preconfigured tool chain for a certain target but just generating
C code from LabVIEW code is not much more than for the wow effect.

Converting a simple VI algorithme into C is quite a bit leaner and meaner when done by hand and converting complex
programs is likely an exercise in vain as there are to many dependencies on the underlying runtime and OS environment
that this could be done in a really generic way .

[Fab]

Did any of you ended up trying the LabVIEW C Generator? Did you try NI's example? I have been trying to make the shipping example work following their instructions and I can not get it to work.

Here is my cross-post including video and snapshots of my steps to follow the instructions in the "Getting Started with the NI LabVIEW C Generator":
http://forums.ni.com...en/td-p/1784658

I am sure I am missing some little obvious step, I just have been away from text based programming for a very long time (thankfully )

Thanks,
Fab

[asbo]

I did play with it briefly, converting a few simple contain VIs to C code. I remember the C code seeming overwhelmingly complex, but that's mostly to be expected. I can't remember if I compiled it or not, but I'm leaning towards no.

Have you tried a screen recording app like FRAPS? That might let you catch what's going on in the window. I can see your target is Linux, have you tried compiling for win32 and checking the results?

[Fab]

Have you tried a screen recording app like FRAPS? That might let you catch what's going on in the window. I can see your target is Linux, have you tried compiling for win32 and checking the results?

I tried with jing when I did the video for the post, but I couldn't see anything, even when I went frame by frame. Compiling for win32 was going to be my next attempt.

I also tried "./GCD.exe" instead of run GCD.exe. That let me see the result, but the result is wrong. I get 1629764006 as a result, which is not the greatest common divisor between 12 and 15 And I get that long number as a reply no matter what arguments I give it. So there might be something else wrong here. If I make it work, I will let you know.

Thanks,

Fab

[Fab]

Since I know some of you might be loosing sleep over this issue
here is the latest response from an AE in the forum post:

"
Hey Fab,

I have been able to replicate what you are seeing using your code. I was originally testing on LabVIEW 8.6 and I think what you have found may be a bug in the 2011 version of the C Code Generator. I am going to continue to work on it here and will post back with a solution or work around when I get it.
"

So, it might be that nobody at NI ever ran this example in LabVIEW 2011 until now...

anyway, I will keep you posted, so you can be able to sleep again

Fab

Edited by Fab, 30 November 2011 - 09:45 PM.