Background
In our company we cooperate with manufacturer of machinery, we are developing C++/Qt crossplatform control applications for devices that they produce. In the past, we used to communicate with their devices through USB (virtual COM port). Now we were informed that this manufacturer plans to switch to LabVIEW (USB Data acquisition). Of cause we will receive relevant information in the future, nevertheless I would like to get some information about it and ask you question which i could not find on internet easily.
I am sorry for noob questions.
Questions
1) What is LabVIEW? Am I right that it is not a single piece of device, but bunch of hardware components, drivers and standards?
2) Who is LabVIEW developer? I have read How much time do I need to learn LabVIEW, but I am not sure. Is it a person who puts LabVIEW components together and makes firmware for them. Or a person who develops toplevel user applications that communicate with LabVIEW?
3) I assume that first part from Question2 would be done by our partner company. Second part will be upon us. But who creates communication protocol? Is there any standard way how DAQ communicates with its PC drivers, or is it upon programmer to develop communication protocol?
4) I have found there is driver for linux at National Instruments. Contains this driver some API/libraries that can be included in C++ code in a standard way and utilized to communicate with DAQ?
LabVIEW is a development environment for creating custom applications that interact with real-world data or signals in fields such as science and engineering. LabVIEW itself is a software development environment that contains numerous components:
G Programming: flowchart-like dataflow programming model
Hardware support: Support for thousands of hardware devices like scientific instruments, data acquisition devices, sensors, cameras, ...
Analysis and technical code libraries: Libraries for signal processing, communication, file I/O, control algorithms, ...
UI components and reporting tools: controls such as graphs, gauges, and tables to view your acquired data and tools to save data to file or databases, or automatically generate reports
Technology abstraction: Using technologies such as FPGAs, multicore CPUs, ...
Models of computation: When G is not appropriate simulation syntax, textual math, statecharts, component-level IP (CLIP) nodes, DLL calls, ... are available
LabVIEW is developed and maintained by National Instruments. It stands behind LabVIEW with comprehensive support, training, and certification options.
LabVIEW makes the process of integrating hardware much easier by using a consistent programming approach no matter what hardware you are using. LabVIEW has freely available drivers for thousands of NI and third-party hardware. In the rare case that a LabVIEW driver does not already exist, you have tools to create your own, reuse a DLL or other driver not related to LabVIEW, or use low-level communication mechanisms to operate hardware without a driver.
LabVIEW is also cross-platform and allows you to deploy your code to many different computing platforms like popular desktop OSs (Windows, Mac, and Linux), embedded real-time controllers, ARM microprocessors, and field-programmable gate arrays (FPGAs).
By the sounds of it you don't need to learn LabVIEW (which is a pity), but you need to learn daq-mx the hardware driver suite by National Instruments. I have no experience with the Linux version (which is a trimmed down or base version of the Windows one), but it basically is a set of dll's or so's that allow you to communicate with their hardware. Try to find out what hardware they are going to use and see if daq-mx base supports simulated devices.
Related
I try to developing simple scada system with C++ in Qt. I want to control hardware or get status(or something) of hardware and send to server or router.(actually my application control softwares too)
And in finish: Qt have a good tools for scada systems?
As of QT 5.7 there is a new Serial Bus library for use with protocols such as CAN BUS and MODBUS, you can read more about it here:
http://doc.qt.io/qt-5/qtserialbus-index.html
For your scenario, QT has plenty of Network support that you could use for your interface, depending on what your hardware specification is. QT does not compare to 'out of the box' SCADA solutions such as a Siemens SCADA system, however developing one based on QT could give you much more flexibility. Depending on what you are trying to achieve, this becomes a trade-off between productivity/time to market and flexibility/value add.
Also there is an opensource qt scada toolkit https://github.com/IndeemaSoftware/QSimpleScada, for visualization.
Are there any out there that are easy to get ahold of? Preferably free, as I don't have any money to spend right now.
What I'm trying to Accomplish
Basically, I'm writing a multi-platform application in native C/C++, and now that I have Linux installed, I feel as though I'm truly ready to make the "multi-platform" development go. Before anyone says "use SDL" or "Qt", note that I'm doing this for an application which I plan to go commercial with (Qt costs money for commercial applications). While SDL is good, I'm also looking to learn about window managers in general. I feel as though the best way to learn how to communicate directly with the operating system is to write the application yourself.
So, are there any resources out there?
First of all X-Windows has nothing to do with Linux.
X-Windows is both a graphical protocol and a GUI system built up around it. X runs on most OSes including Windows and Mac. The most typical scenario is for an X application to run on a multiuser computer running a UNIX-like OS (for instance Linux) and for the users to interact with it using an X-server which runs on either an X-terminal or a desktop OS. The X-Server is a standard piece of the X-System. If you install an X-Server on Windows then you will be able to interact with graphical applications running on one or more other computers.
It sounds like you want to focus on building the X applications, not the device drivers or the server or any other part of the X-system. Linux is as good a choice as any, but the books and documents that you need were likely written using Solaris or BSD UNIX. But it's the same API.
Since X has been widespread since at least the early 90's, look for books in secondhand shops and university jumble sales. Advertise on Craigslist for X related books.
The lowest level API for X is called Xlib. Toolkits like GTK and QT are layered on top of this so studying their code is a good way to learn how to do things. But there is also something called the X-Toolkit that runs over Xlib and used to be the foundation layer for GUI toolkits like Motif and others. If I were you I would start with X-Toolkit, to get familiar with all the component parts of X and how they interact. For instance, it will take you a while to get used to the fact that a window manager which manages the windows on an X-Server display, doesn't run on the X-server but runs on a remote system. Or that you can have apps running on Linux and OS/X and Solaris all displaying their windows on the X-server on a single Windows box.
Google X Toolkit intrinsics to get all kinds of info including free reference manuals.
As you read more about it you will come across a lot of other unique terms that you can google to get additional info and a broader perspective. Don't spend too much time with old toolkits like Athena Widgets or Motif.
Since there were more people programming X in the early days of the Internet than today, the USENET FAQs are still a good source of introductory tips, e.g. http://www.faqs.org/faqs/Xt-FAQ/
You can write your app as a server in C. Call it Engine. No need to think about the User Interface. After that you can create interface in Qt. The communication protocol will be public (or private) and your Qt application will be open-source. Later if you like you can create many more interface to your application. Such as web interface, Gnome interface, C#.NET interface etc.
Coming from C++ & MFC background, is there any better (maintainability/customization) platform in developing application GUI ?
We are developing industrial applications (machine vision), where :
-Performance-critical (mostly image processing in CPU atm, but GPU is up next)
-Low level hardware interfacing (inhouse PCI device, frame grabber, motion card)
-Real-time data visualization (images / statistical graph)
-Future roadmap includes networkability for distributed processing and remote access.
Cross-platform will not be important for us since the system runs in controlled-environment (customer only cares whether the system runs and they got their output).
There are also concerns on migration cost (3rd party dependencies, training cost for developers and service personnel)
Edit
Clarification on the "image processing" mentioned above:
I'm referring to "picture" (2D information in matrix format) rather than graphic (commonly 3D vectorized). Currently we uses 3rd party imaging library (for spatial domain processing like segmentation, OCR/OCV, morphology, pattern match) and incorporate our result logic.
If you need performance-critical graphics processing, then C++/DirectX or C++/OpenGL are your best bets, hands down. C++/DirectX is arguably the more maintainable of the two.
That said... depending on the actual processing you're doing, you might consider moving portions of your UI to a more maintainable platform. The .NET framework / WPF can do some pretty amazing things, and with good implementation of patterns like MVVM and can be amazingly maintainable. Ditto the networking side; WCF abstracts a lot of common protocols away from the code, making for cleaner, more maintainable networking code. You can even write your translation layer between your unmanaged processing and your managed layer in C++/CLI.
That said, it's all very subjective. I can't tell enough from your bullet points to make a good judgement on whether or not you can offload some or even all of your processing to .NET/C#. It's worth considering, but my gut tells me that it's probably not your best bet.
As a fan of Qt I would be remiss not to mention it.
Although cross-platform is not one of your criteria, it is a nice bonus.
Qt also has good video hardware support through OpenGL (I'm not sure that it will help with capture hardware though).
It is open-source so you can get your hands as dirty as you like.
It is highly customizable.
It is actively developed and has a large community.
MFC programmers should not have much trouble coming up to speed.
You should also read through some of these questions and answers:
Good C++ GUI library for Windows
https://stackoverflow.com/questions/610/gui-programming-apis
What I had did before when developing a C++ scientific application is that, it will develop it completely under console based application. The console based application will able accept various type of command from user keyboard, and perform action accordingly. For example :
image_processor > load input.png
image_processor > save out.png
The good thing on this is, I can 100% in concentrating my algorithm design, without worry much on how to fit into the GUI framework. Either they are MFC or QT.
At the end of day, instead of taking input from keyboard input stream, I will just simply hook my console based application's STDIN, to the GUI application communication channel. My GUI application will then string based command, to talk and receive feedback from the console application.
Guess what I use to develop the GUI? Java Swing :)
I guess I am taking Unix people approach. See what Joel says :
Suppose you take a Unix programmer and a Windows programmer and give them each the task of creating the same end-user application. The Unix programmer will create a command-line or text-driven core and occasionally, as an afterthought, build a GUI which drives that core. This way the main operations of the application will be available to other programmers who can invoke the program on the command line and read the results as text. The Windows programmer will tend to start with a GUI, and occasionally, as an afterthought, add a scripting language which can automate the operation of the GUI interface.
I realize by taking Windows approach, you will end up with a more user friendly application. However, if your main concern is to get the sophisticated algorithm written well and GUI is the secondary, I would suggest that you go for Unix approach.
My friend is working on a project in which he needs to get some digital signals into a computer to display/manipulate them.
So I advised him to insert those signals into a USB port due to it's popularity (because the device (which outputs the signals) and the program used for display and manipulation should both be designed for real world usage and might be sold in the market)
The targeted platform is Windows primarily but it would be better if the software was cross-platform.
And my friend has knowledge in C++, and wouldn't mind learning C as well.
Where should he start, and what are the steps to get the signals into memory?
Many Thanks
There is a great article here: USB hardware/software integration that describes the process in full.
Get a Labjack or one of the Phidgets. (I've used the former several times, not the latter) They're fairly inexpensive and both have Java driver support, among other things. (like LabView drivers)
There are more ports on computers, and many ports are easier than USB. USB supports 127 devices, and therefore devices have to cooperate. On the other hand, a microphone input is meant for exactly one input. You can sample it at 8 bit/22Khz or better, and typically you get HW buffering. You can also use existing drivers, and simple APIs.
The library should;
Be easy to use and few lines of client code should accomplish much
Be as platform independent as possible. (In case of future ports to other platforms)
Have C++ bindings.
Be mature and stable
I would also like to be notified of most HID events through callbacks.
I have considered the following alternatives:
libhid - (Unfortunately?) this is GPL and cannot be used in my application.
WDK - Seems to be a bit low-level for my use. I don’t need that kind of control.
atusbhid - This has an appropriate level of abstraction, but it is firmly tied to the Windows messaging loop
Are there other alternatives to offer?
Take a look at hidapi: it is C, which answers the C++ bindings question (effectively :)), is cross platform and has a very permissive license.
It doesn't appear to have the callbacks, but...
If libhid works for you, then perhaps the thing to do would be to write an application (which you would GPL), which uses libhid to talk to devices, then provides whatever you need via a TCP connection. Your real application would connect via TCP to do what it needs. This would obviously be a massive performance hit.
This application would effectively be a 'shim' between libhid and your application. In this case, the shim would exist for legal, not technical, reasons.
I'm not saying it's a good idea, just that it's an idea.
Consider rolling your own. You'll have total control over the interface, the level of platform independence, and such. Even though a project is GPL, you can use it as a recipe for your own, and as a testbed to find issues with your own.
There are several USB HID host drivers for Windows. An easy-to-use dynamic-link library is from http://embedded24.net.
There are also several example applications included for Visual Studio 2010 (C++, C#, and Visual Basic).
HIDmaker software suite from Trace systems is an option.
Pros:
Easy to use (excellent for learning how to program for USB HID)
Generates working applications source code in a various project formats (Visual Studio and Borland)
Generates stable example code for both host and device (stable in my experience)
High performance (if HID can even be said to have high performance in the first place)
Cons:
Only works on Microsoft Windows
Uses its own USB library I think (ActiveX)
Look at this code:
Read and use FM radio (or any other USB HID device) from C#
It gives you some simple classes to talk to a HID device. It boils down to getting the alias for the device (something like \?\HID#Vid_nnnn&Pid_nnn#...) and use CreateFile to open it. You can get the device's alias under HKML\SYSTEM\CCS\Control\DeviceClasses\{4d1e55...}\.
The Vid and Pid are the vendor ID and product ID of the device (check Device Manager).