LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Opinions Please - Non Test & Measurement LabVIEW applications

Hi Guy's,

 

Just wanted your opinions and experiences really. 

We know that LabVIEW is targeted towards the Test & Measurement applications used in industry but what about using LabVIEW to develop software applications that are not targeted towards Test & Measurement?

 

Point of Sale software (EPOS), SQL Database front end software for business management, CRM software etc.

Is there any reason we can't use LabVIEW for these types of applications? Are other IDE's better suited towards these types of applications for any reason? Really, at the end of the day, LabVIEW or G is just another language to create software applications, but generally, you don't se it be used to develop these types of software packages.

 

Let me know your thoughts.

Thanks

 

 

 

 

0 Kudos
Message 1 of 12
(2,209 Views)

LabVIEW is not a general purpose language. But still, i could imagine using it for non measurement/test applications. For example, i created a front end for GLE (Graphics Layout Engine) using LabVIEW, to make prototyping graphs for scientific publications faster. 

Another thing is that, use wording more careful. IDE != computer language...

0 Kudos
Message 2 of 12
(2,200 Views)

I believe VIPM is made with LabVIEW. I would consider that a novel application.

 

mcduff

0 Kudos
Message 3 of 12
(2,176 Views)

@Blokk wrote:

LabVIEW is not a general purpose language.


Tell that to Altenbach.  He uses LabVIEW for math.  Lots and lots of weird math.  No hardware interface.

 

From what I have seen with plans for NXG, I think there will be some push towards more general applications such as web pages.  There are already plenty of interfaces for databases in LabVIEW, some using .NET or ActiveX.

 

But, let's face it, NI created LabVIEW to sell more hardware.  It will always keep its focus on test, measurement, and industrial control and monitoring.  But people expect more from their test systems.  NI will have to keep LabVIEW ahead of that.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 12
(2,124 Views)

@Blokk wrote:

LabVIEW is not a general purpose language.


Wow, then I must be doing something wrong because I have been using LabVIEW for 20+ years and almost never use any hardware. Why would you make the claim that it is not a general purpose language? What is missing?



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 5 of 12
(2,083 Views)

@Mark_Yedinak wrote:

@Blokk wrote:

LabVIEW is not a general purpose language.


Wow, then I must be doing something wrong because I have been using LabVIEW for 20+ years and almost never use any hardware. Why would you make the claim that it is not a general purpose language? What is missing?


I make the claim based on popularity. So i guess I wrote my sentence not careful enough? I could also write "LabVIEW can be used for anything, but there are much more popular general purpose languages, like Python or C#...etc"

0 Kudos
Message 6 of 12
(2,070 Views)

LabVIEW is a general purpose language, but it is much more suited to applications involving hardware (due to good integration with NI hardware / 3rd party devices). Especially when you look at something like the cRIO where you can program a PC / RT target / FPGA using a common language.

 

I have written applications in the past that don't have any involvement with hardware - I wrote a reporting tool for viewing/displaying test data for my current client. I had to use LabVIEW because they want all of their software in the same language for maintainability reasons but I had initially recommended that they went for a web-based solution instead since:

a) LabVIEWs database support isn't that great. Other languages have some sort of MVC / active-record implementation which makes displaying/handling/editing business logic data a lot easier. Performing CRUD (create-read-update-delete) database operations is a pretty manual/tedious process.

b) Making a nice customisable graph UI is difficult with only one real graph option (XY graph) in LabVIEW. Most of the time was spent creating a custom plot legend (as it needed to display a dynamic number of datasets/plots). If it was on the web - there are lots of different graph toolkits/frameworks available

c) They could have accessed it on any PC without requiring the LabVIEW runtime engine to be installed

d) Making UIs dynamic isn't that easy in LabVIEW (e.g. window scaling, dynamic numbers of tabs, displaying tree data). Yes - it's mostly possible (or you can work around it), it's just easier in other languages.

 

So it's just about choosing the right language/tool for the job - the web is great for the display/presentation of data, but rubbish for any kind of hardware integration which is what LabVIEW excels at.


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 7 of 12
(2,051 Views)

@Sam_Sharp wrote:

LabVIEW is a general purpose language, but it is much more suited to applications involving hardware (due to good integration with NI hardware / 3rd party devices). Especially when you look at something like the cRIO where you can program a PC / RT target / FPGA using a common language.

 

I have written applications in the past that don't have any involvement with hardware - I wrote a reporting tool for viewing/displaying test data for my current client. I had to use LabVIEW because they want all of their software in the same language for maintainability reasons but I had initially recommended that they went for a web-based solution instead since:

a) LabVIEWs database support isn't that great. Other languages have some sort of MVC / active-record implementation which makes displaying/handling/editing business logic data a lot easier. Performing CRUD (create-read-update-delete) database operations is a pretty manual/tedious process.

b) Making a nice customisable graph UI is difficult with only one real graph option (XY graph) in LabVIEW. Most of the time was spent creating a custom plot legend (as it needed to display a dynamic number of datasets/plots). If it was on the web - there are lots of different graph toolkits/frameworks available

c) They could have accessed it on any PC without requiring the LabVIEW runtime engine to be installed

d) Making UIs dynamic isn't that easy in LabVIEW (e.g. window scaling, dynamic numbers of tabs, displaying tree data). Yes - it's mostly possible (or you can work around it), it's just easier in other languages.

 

So it's just about choosing the right language/tool for the job - the web is great for the display/presentation of data, but rubbish for any kind of hardware integration which is what LabVIEW excels at.


And not to forget that, some of your points will be "fixed" in a few years, when NXG will grow into a real product. Web support, vector graphics, etc...

0 Kudos
Message 8 of 12
(2,048 Views)
Indeed! I am hoping most/all of my UI/data display gripes will disappear! 🙂

LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 9 of 12
(2,039 Views)

In my opinion, LabVIEW offers the following "Features" that are more "naturally available" than in other (usually text-based) languages:

  • A more "intuitive" and potentially more self-documenting presentation of the code and its algorithms (1 Picture = 1000 words).
  • "Natural" parallelism.
  • "Time" as a primitive, making simulations somewhat more "natural".
  • A "Drag and Drop" approach to designing the User Interface, making "tweaking" the looks simple, and processing the controls and indicators "natural".
  • (Relatively simple) Recursion.

Needless to say, I've got a lot of non-hardware LabVIEW code ...

 

Bob Schor

Message 10 of 12
(2,035 Views)