Why Convert from LV to C++?

[TLE]

We have a large LabVIEW application with about 3 years of development
invested. It interfaces with a DAQ card to drive impedance sensors
and read the response. Cure time calculations are executed after the
response is analyzed based upon a set of rules. The rules come from
an Access database (SQL toolkit). Cure times are displayed on a run
chart (SPC toolkit). The GUI consists of about 10 screens.

A co-worker wants to start transitioning from LabVIEW to C++. He
believes that this will improve the performance, maintainability, and
flexibility of the application. I need to know the pros and cons (in
detail) of such an undertaking so that I can respond to this request.

Who else has tried such a project?

I like LabVIEW but am willing to
transition to C++ if it will be worth
it in the end.

Thanks!

Tim Erickson
Director of Software Development
Signature Control Systems

[Labviewguru]

Fire your coworker!

There is no truth to what he says. C++ doesn't provide any of the advantages that he listed, and you will suffer greatly for trying to transition the code!

[Labviewguru]

Two additional points:

First, it is quite easy to learn LabVIEW. Your coworkers will find it quite easy to learn.

Second of all, LabVIEW is much easier to transition code from one developer to another. There are far fewer mysteries about how the code does what it does, and your developers won't have as hard a time making improvements, or adding features.

There is one strong recommendation I have for you though regarding your current code: make sure it uses some form of programming guidelines to make the code consistent.

[Dennis_Knutson]

It sounds to me that your co-worker is either a very inexperienced LabVIEW programmer or a very experienced C++ programmer with no desire to learn LabVIEW. The one time I did a similar project was when I had to create an instrument driver in both LabVIEW and CVI. The perfomance of both was identical.

There can be differences in performance between the two languages but they're often very small and usually depend on what you're doing. I don't think you'll see any difference in DAQ. The LabVIEW VIs call the same dll that he'll have to call in C++. You might want to look at optimizing your current application and see where the time is being spent and whether you've got some inefficient algorithms. You don't mention what version of LabVIEW that you're using -
an upgrade here might help as well.

[wiebe@CARYA]

Hi,

Converting to C++ will typically result in MAXIMUM 10% increase in speed.
(This is execution time, not development time.)

If speed is an issue using external code for high performance routines joint
the best of both worlds.

If your converting LabVIEW to C++, your probably the first to to this. Most
companies do it visa versa. Best way to do this is to make a LabVIEW DLL of
the fast routines and make a C++ DLL that can replace it.

Ask the local NI for a presentation for the management, they have to be
convinced. Also, ask your co-worker why he beleves LV is less maintainable.
LV does need some rules ('coding guidelines') you'll have to build together,
to make it maintainable.

If your co-worker rewrites the code, he'll probably end up with faster, and
better maintainable C code. This is because he has a clear specification (a
working program), while the old LV code is the result of three years of
coding (probably by different persons), without detailed specifications.

Regards,

Wiebe.




"Tim Erickson" wrote in message
news:aa216f94.0207160828.4ceb8aeb@posting.google.com...
> We have a large LabVIEW application with about 3 years of development
> invested. It interfaces with a DAQ card to drive impedance sensors
> and read the response. Cure time calculations are executed after the
> response is analyzed based upon a set of rules. The rules come from
> an Access database (SQL toolkit). Cure times are displayed on a run
> chart (SPC toolkit). The GUI consists of about 10 screens.
>
> A co-worker wants to start transitioning from LabVIEW to C++. He
> believes that this will improve the performance, maintainability, and
> flexibility of the application. I need to know the pros and cons (in
> detail) of such an undertaking so that I can respond to this request.
>
> Who else has tried such a project?
>
> I like LabVIEW but am willing to transition to C++ if it will be worth
> it in the end.
>
> Thanks!
>
> Tim Erickson
> Director of Software Development
> Signature Control Systems

[Ben]

Hi Tim,

I used to program in C++.
"I got better" (Monty Python Quest for the Holy Grail).

There are two situations where I will turn to C++.
1) Bit stuffing, and the like (can't beat the speed).
2) Adapting manufactuer supplied C++ drivers to LV.

If you don't have to deal with either of these issues, you will be better off using LV.

I once wrote an app single-handedly using LV in 3 months.
The customer said "If we did that in house [using C++] is would have taken 6 people 18 months to complete it."



Ben

[TLE]

Thanks for all the great feedback!

One more thing my co-worker would like to be able to do is provide
"maintainence" packs for the application. In C++ you could do this by
providing an updated DLL. Is there a way to substitute an updated VI
into a LabVIEW application without having to re-deploy the whole
thing? Our LabVIEW application is about 15 MB but we would like to
provide updates on a single floppy.

[Labviewguru]

TLE,

Not only is this possible, and not only do I strongly recommend it, but it creates a situation that is not possible in C/C++.

As of the moment I finish this entry, I am writing an article for Developer Insights and/or LTR about this issue... I just talk about this too much...

Here is what you do:

When you create (or reorganize in your case) your code, do so in a deployment evironment, as if the client were to run the program from LabVIEW. In other words, have a directory structure such as this:

\root\program\code - place main here - you will eventually substitute this with the executable
\root\program\code\support - place support files here
...\code\tests - place test VIs here
...\code\controls and typedefs - self expl
anatory
etc...

Once you have reorganized, and relinked everything, you need to now create a loader application. This is a very simple single VI that has no subs. It merely uses the VI server to load the main VI and run it. You can even get fancy here and preload some VIs into memory for efficiency, or anything like that. I have even used a "splash screen" to indicate what is being loaded. Done properly, this looks very professional.

There are several advantages to this method. However; there is a significant disadvantage. Your source code IS your deployed code. You can fix this by using VI server to programmatically remove diagrams and/or lock VIs for security. Still, you have to deal with all of the subVIs being available to the user.

To me, this is not a serious hindrance. The advantages far outweigh this anyway. First, you have, as you need, the ability to update the software very easily. As long as you don't change the interfaces of any VIs you want to update
, you can just substitute the VI very easily (if this doesn't work well, use the VI server to load any VIs that may be dynamic.) Also, you now only have to archive your software once. Also, you only ever have to build the application once.

[TLE]

I am sorry to keep beating this horse but my co-worker also mentioned
Delphi. Is there any benefits of Delphi? I would assume that Delphi
is very similar to C++ regarding the pros and cons of transitioning
from LabVIEW.

Thanks!

[Labviewguru]

If memory serves me, Delphi is a compiler of C on Linux systems (Unix).

Well, guess what...there is LabVIEW for Linux.

Put your coworker on. Let us beat him up. We may have already. He sounds like a typical (all three of them) LabVIEW basher to me. In saying that, I mean, that he is so used to C/C++, and unfamiliar with LabVIEW, that he doesn't have all the necessary data to be able to form a valid opinion on the matter.

The fact that you have created the application using LabVIEW should be evidence enough to you that this guy may be wrong about LabVIEW. LabVIEW is quite capable, with only a few minor performance differences. If you asked me the biggest difference between C and LabVIEW, I would tell you it was in the compiled and deployed code (built applications.) LabVIEW utilizes ALL libraries when it builds an application. C/C++ only utilizes those that are necessary. To me, LabVIEW is in fact NOT viable as a language for creating commercial applications that don't involve: A) DAQ; B) Communication; or C)automation. In such applications, LabVIEW is king, and the space required by such an application would likely be necessary for an equivalent C/C++ Application. I have been begging National Instruments for a version of LabVIEW that would allow commercial software (such as CGI programs) to be possible. With that ability, LabVIEW would be the ultimate language, and I wouldn't need to learn C/C++. As it stands, LabVIEW is a far superior language in most aspects (except this one very important one) and I can't see using anything else. LabVIEW is very easy to learn, to program with, and also to maintain, upgrade, scale, and pass on to other developers. C/C++ requires programmers with a lot of education, a lot of experience, AND a great deal of skill and being meticulous about programming in order for code to be successfully maintained, scaled, or upgraded.

In returning to your original concern, yes, Delphi has the same transitioning issues as LabVIEW.

Send your coworker to a couple of LabVIEW courses, or one of the free hands-on seminars. Better yet, send him to me, I'll fix him.