LabVIEW or Visual C++

Discussion in 'Programmer's Corner' started by kevin.khan, Jul 25, 2013.

  1. kevin.khan

    Thread Starter New Member

    Jul 9, 2012
    23
    0
    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.
     
  2. tshuck

    Well-Known Member

    Oct 18, 2012
    3,531
    675
    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...
     
  3. kevin.khan

    Thread Starter New Member

    Jul 9, 2012
    23
    0
    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++.
     
  4. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998
    I made a GUI in C++, and it took FOR-EV-ER! There's alot of crap you have to learn.
     
  5. tshuck

    Well-Known Member

    Oct 18, 2012
    3,531
    675
    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...
     
  6. tshuck

    Well-Known Member

    Oct 18, 2012
    3,531
    675
    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.
     
  7. mcgyvr

    AAC Fanatic!

    Oct 15, 2009
    4,770
    970
    Labview is far from cheap too.. $$$$$

    How about a java/android app?
     
  8. odinhg

    Active Member

    Jul 22, 2009
    65
    15
    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/
     
    kevin.khan likes this.
  9. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998
    What's the learning curve?
     
  10. kevin.khan

    Thread Starter New Member

    Jul 9, 2012
    23
    0
    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.
     
  11. WBahn

    Moderator

    Mar 31, 2012
    17,743
    4,795
    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 ...?
     
  12. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,388
    1,605
    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.
     
    tshuck likes this.
  13. GetDeviceInfo

    Senior Member

    Jun 7, 2009
    1,571
    230
    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.
     
  14. Jack_K

    Active Member

    May 13, 2009
    115
    0
    LabView is single threaded.
     
  15. odinhg

    Active Member

    Jul 22, 2009
    65
    15
    This is not true. Current versions of LabVIEW does support multithreading. It is even very easy to implement too.
     
    ErnieM likes this.
  16. iPromise

    New Member

    Aug 11, 2013
    15
    0
    Why don't you instead of using CreateWindow/Ex to create your window use a resource file and call DialogBox?
     
  17. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998

    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.
     
    Last edited: Aug 12, 2013
Loading...