11-22-2011 09:58 AM
We explored using sbRIO for our project, for different reasons we ended up going with a different embedded solution . We are currently evaluating the LabVIEW C Generator to convert some of the core analysis routines from LabVIEW to C so the team that will be creating the embedded solution don't have to re-implement them from scratch.
Before converting our code, I followed the instructions given in the "Getting Started with the NI LabVIEW C Generator" manual to create a static library created inCygwin using GNU Compiler Collection (GCC).
I managed to compile the code, but when I type "run GCD.exe" in the Cygwin console, I just see the window flash with no time to see if the result is correct or not. I modified the main.c cde to add a getchar(), but the window still just flashes and now I am left with the GCD process still running and have to kill it using Windows Task Manager.
Has anyone else got this example to run? I am sure I am missing an obvious setting or step, please help me.
More details below.
Thanks,
Fab
Here is a video showing the steps I followed
If you don't want/can't see the video. Here are some screenshots of what I have done so far:
GratestCommonDivisor.lvproj C Generation build specs Information:
C Function prototype definition:
I copied Makefile located at: C:\Program Files (x86)\National Instruments\LabVIEW 2011\examples\CGenerator\Tutorial\Cygwin
and replaced both Makefile and Makefile.cygwin in the directory where the C code was generated
I also copied main.c from the same location and replaced the one generated
Here is the snapshot of the results after executing "make GCD.exe"
Then to run it I just type
I see a window open and close really quickly and I never see the result. I have tried adding the getchar() line to the main.c file, but still I don't get to see the results.
11-22-2011 10:50 AM
A friend pointed out that I should try "./GCD.exe" instead of run GCD.exe. That let me see the result, but the result is wrong.
you can see that definitely 1629764006 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.
The code works well in LabVIEW
11-23-2011 01:29 PM
Hey Fab,
I have tried this tutorial myself and I am getting the correct results. Could you attach the code you are using to see if I can replicate what you are seeing?
11-29-2011 09:09 AM
Hi Kevin,
I hope you had a good Thanksgiving. I am attaching a zip file with the LabVIEW project, my build specification and my version of "Greatest Common Divisor.vi", which should be the same as the one that you have that ships with the LabVIEW C Generator, but just in case. I am also attaching a zip file with the C files generated by the LabVIEW C Generator.
You can also see the video I posted earlier with the steps I followed. I hope you are able to point out where I went wrong.
Thanks,
Fab
11-30-2011 03:07 PM
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.
11-30-2011 03:40 PM
Kevin,
Just to be clear, this code ships with LabVIEW C Code generator, I just followed the steps in "Getting Started with the NI LabVIEW C Generator" guide. So, you should be able to reproduce it by following those steps using LabVIEW 2011. If you don't get the same results, then it might be something with my system.
Thanks,
Fab
11-30-2011 03:43 PM
Hey Fab,
I think I misspoke. I have been able to reproduce what you are seeing with 2011 with the code that ships with it. Initially I thought I had created a working version since I wasnt getting that large int you were seeing but I am also getting the same incorrect result over and over again.
11-30-2011 04:21 PM
I have verified that the code works when built using the C Code Generator with 2010 so I have filed a Corrective Action Request for this issue. I will post back to this forum with any updates.
12-11-2011 01:36 PM
Kevin,
Thanks for following up on this. Would you please put the CAR #?
Thanks,
Fab
12-12-2011 09:06 AM
This issue is CAR##327027. It is still being looked at by R&D. I will update here when I have more information.