LabVIEW or JAVA or C-Sharp!!

[knowme555]

When the hardware complexity increases, then there are some limitations of C langauge ,then it is better to switch over to an object oriented langauge?

when the hardware complexity increases and also software complexity increases, then is this true that instead of using labview, we can use C-sharp

or java..?

I give an example, that when we have a very complicated Hardware setup including spectrum analyzer, logical analyzers and alot... the circuitry is very

 complex for LAbVIEW with C, then many people will find it convenient to switch to Obj.Orien. Language like C-Sharp?

What would you say ??

Thanks n Best Regards,

James,

[becktho]

Generally I would say that the selection of a programming language should not depend on the complexity of hardware.

I would rather take the following points in consideration:

- which plattforms will the program run on
- what kind of hardware will be controled
- are there existing drivers -> if no, how easy is it to develop it on your own
- what kind of elements should the frontpanel contain (e.g. graphs or charts, tables, ...)
- is the language a standard or rather a derivative which is supported by a single company
- last but not least: how much does it cost (java could be downloaded for free as well as diverent IDE)

This is what I would look at, but I'm quite sure that there are other opinions.

Message Edited by becktho on 09-21-2007 10:31 AM

[rolfk]

---

@knowme555 wrote:

When the hardware complexity increases, then there are some limitations of C langauge ,then it is better to switch over to an object oriented langauge?

when the hardware complexity increases and also software complexity increases, then is this true that instead of using labview, we can use C-sharp

or java..?

I give an example, that when we have a very complicated Hardware setup including spectrum analyzer, logical analyzers and alot... the circuitry is very

 complex for LAbVIEW with C, then many people will find it convenient to switch to Obj.Orien. Language like C-Sharp?

What would you say ??

---

Hardware complexity shouldn't really be the main factor here. In general you can safely assume that accessing instrumentation hardware in LabVIEW is easier than in any other language provided you know them both equally well.

In every case I have seen so far where a particular programming environment was chosen above another one it was more because of familiarity with it than because of presumed ease of programming. Only when the familiarity with the different programming environments is at similar level (which can be close to 0) start things like ease of use to be predominant. I for one will go to great lengths to create just about any system integration project in LabVIEW because I know how to do it if it can be done at all. And while LVOOP may help with larger projects it is definitely not necessary for them. I've written LabVIEW programs with 1000 VIs and more that would have taken ages to do in C or even C++ and they are generally working very well long before any formal OOP was introduced to LabVIEW in any form.

Doing the same in C#, or Python, or Lua or name whatever you want would require me a lot more work upfront to learn and see how things would need to be done to make them work at all.

In general any question like the one you pose is either out of ignorance or to provoke a heated discussion of the pro an cons of particular environments. In the end the only thing that really matters is if one can and will learn a particular paradigma to work with and of course if one can create a solution that works satisfactorily in that environment. As such what is right for you may be completely wrong for me.

Rolf Kalbermatter

Message Edited by rolfk on 09-21-2007 10:51 AM

[Graziano]

Hi!
   Nice post....
 
   I agree with answers above.  I just add that in my opinion, to say it straight, if you use a complex set of NI Hardware, LabView should be the choice, because each instrument can be easily controlled by simple VIs,  (respect to code you need in other languages).

   I think the problem can be the software: what's your task? Are you going to deeply integrate your app into a complex Software system?

   For short: the choice of language should strongly depend on Software complexity (and maybe performance constraints).

   Please, let us know what your final choice will be, I think it's interesting!

graziano

[parthabe]

IMO, LabVIEW is the language for all s(r)easons.

[shoneill]

Complexity of a task has little or nothing to do with software language which "should" be used.

Your architecture should reflect the complexity of the project.  This architecture can mostly be implemented in any language you choose.

Object-oriented programming won't neccessarily solve complexity problems for you.  If you don't know what architecture to use, you'll have problems with ALL languages.

A lot of aspects of software engineering can be used well without object-orientation.  Encapsulation, coherence, cohesion, interfaces.......

Still, LabVIEW's clearly the only choice.....

Shane.

[Ray.R]

Hardware complexity is a different issue to the software.  The decision to go for O-O is matter of SW architecture, not HW.  Increased HW complexity does not necessarily mean a linear increase in SW complexity either... Actually, it can be the other way around 😉

Actually, in my opinion, going to any language (C-sharp, etc) should not be based on HW, but rather experience with that SW, and what is the intention of that language.  For instrument control, there's no doubt in my mind that LV tops them all.  For embedded HW (firmware), usually I go with C.  Windoze applications, C++.

What you are describing for HW are instruments.  I would not find it convenient to use C# for automating instruments if LV is available... that's a "no brainer".  🙂  C# would be "inconvenient" for me because of lack of experience with the language... but then again, what instrument support do you have with C#??? 

The word "complicated" is very relative.. To me, instruments like spectrum analyzers, logical analyzers, etc, are very simple HW... They exist!  They have drivers! I don't need to design them and write firmware..  Thus, they are very simple to use & implement with LV 😄   

I also agree with the other posts... We're all saying something similar..    Rolf summed it up nicely in his last paragraph.. 

😄

Message Edited by JoeLabView on 09-21-2007 08:24 AM

[Graziano]

Just a note...
   you are posting on LabView forum, it's quite notmal to get these enthusiastic suggestions to use LabView... but I guess that if you post on a Java forum you won't get the same result

   Just try, maybe I'm wrong...
  
    Have all a nice (fri)day!

graziano

[pallen]

With a few much more experienced LabVIEW programmers already answering, I probably don't need to chime in too.  But as I've only been using LabVIEW for a few years my perspective might be a little different.

If the hardware you're using is supported by LabVIEW, (ie.NI Stuff) then it's very likely that it's your best choice.  If you've got a lot of hardware, I like the way you can organize things into smaller pieces with SubVIs.  

We've done some fairly complicated machines at our shop, and no one has ever used any OO architecture either in LabVIEW or anything else.  I'm sure it has it's uses.  But just because you've got a lot of hardware doesn't mean you need to use it.  

Not being a C programmer though, I'm sure my view is a little slanted.