Hi there,

I need some advice from my fellow programmers. I currently work on a project that involved creating a USB controller board (USB protocol is handled using the UM232H module from FTDI). The controller card is used in an acquisition system, which contains 64 channels.

I have completed the hardware, but now the software needs to be attended to. I need to develop a GUI that should have a real time display (at least 32 channels need to displayed at a time), and should also support multithreading and multiprocessing.

Now I have to make a decision about which program language to use, LabVIEW or Visual C++. I have very little program experience either one, so I don't real know which one would be best to develop a GUI and also be able to display real time data and allow for multithreading and multiprocessing.

 

I'm not familiar with LabView (isn't it basically drag-and-drop applications?) but using C++ isn't too hard for a low-level interface.

Personally, I would consider making a C++ interface, wrap it, and pass it along to a C# GUI that can be as fancy, or basic, as necessary...

 

I believe in LabVIEW functions are presented in blocks to form a block diagram (as opposed to text based programming).

Sorry to ask such an amateur question but why exactly would you wrap c++ interface and pass it along to a c# program. What advantages does c# have or c++.

Also do you know how easy it is to achieve multithreading or multiprocessing in c++.

 

I made a GUI in C++, and it took FOR-EV-ER! There's alot of crap you have to learn.

 

I remember someone once saying that LabView requires no programming knowledge to do anything... If you can rely on proprietary software, it may be the way to go...

C#, or WPF in particular, offers huge amounts of GUI customizations and nice visuals. Using WPF, you could bind to your data, which would update automatically when updated. However, C# is a managed language, meaning you don't have access to memory (at last not easily). It can run in an unsafe mode, where you can do pointer arithmetic and access memory(what makes it unsafe), but it gets pretty confusing mixing managed and unmanaged code sometimes.

The wrappers aren't really necessary if you go the unsafe context route in a C# application.

Multithreading is pretty straightforward in either language...

 

I made a GUI in C++, and it took FOR-EV-ER! There's alot of crap you have to learn.

That's why I usually try to get into a higher level language as fast as possible for GUI work....

C++ GUIs are usually quite cumbersome.

 

Labview is far from cheap too.. $$$$$

How about a java/android app?

 

If you have access to a LabVIEW license, then it's a great tool for getting fast results. But as said above, it's very expensive unless you can buy the student version.

What about using Qt/C++? Qt is free and comes with a nice GUI-editor.
http://qt-project.org/

 

How about a java/android app?

What's the learning curve?

 

Alright thanks guys. I think you are definitely selling on c++. I have one final question. What would be a good graphing toolkit available in c++. As I stated I will be acquiring data from over 64 channels and need to display at least 32 of these channels.
What I envision would be something like this:
http://cdn.medi-shop.gr/stories/ecg.jpg.

 

You need to consider a number of other things. For instance, what is the intended application? Just one system someplace where you work? Or is it going to be replicated and sold to other users? Who is going to maintain it? The answers to these and other similar questions can really shift the needle.

Why are you only considering LabView and C++? Why not MatLab? Why not Excel? What not ...?

 

And why not Visual Basic, one of the most friendly of the RAD (Rapid Application Development) languages out there?

As an aside, anyone saying LabVIEW "requires no programming knowledge to do anything" has no knowledge of LabVIEW. While it is specialized towards automation of test instruments there are no fundamental limits on what it can produce. It is also a proprietary and closed language. And it is expensive too.

 

with Labview's rich collection of resources, you could produce a finished product in short order. With C, you'd need a library of routines to even come close in regards to development time. It's a no brainer, assuming you already have Labview.

 

LabView is single threaded.

 

LabView is single threaded.

This is not true. Current versions of LabVIEW does support multithreading. It is even very easy to implement too.

 

I made a GUI in C++, and it took FOR-EV-ER! There's alot of crap you have to learn.

Why don't you instead of using CreateWindow/Ex to create your window use a resource file and call DialogBox?

 

Why don't you instead of using CreateWindow/Ex to create your window use a resource file and call DialogBox?

I was trying to create a custom test panel to look like a protocal analyzer such as a stand-alone instrument would look. My graphics was supposed to mimmic a panel with switches, text displays, indicator lights, rolling displays, etc. I got it all to work, though it didn't really look much like a commecial instrument. I could have used some better artistry.

Besides, I was using the principle of learning from the ground up. I had no idea how long it would take. That said, I was reasonable pleased with the result. I even had multiple threads updating various test displays.