Phil Schmidt wrote: > Well, that kind of gets right to my point. Does the "added" effort with > Python to interface with data acquisition hardware really result in > less productivity? I am very familiar with Matlab, Labview, and Python, > and frankly, Python is the most productive and powerful programming > language of the three. But it's the hardware compatibility thing that > concerns me with Python.
This is really a question that has no general answer. It depends on the specific hardware and the solutions available. Generally, Matlab and Python sucks equally much when it comes to interfacing with hardware. Both tycan use C extensions (which you may have to write) or ctypes (Matlab's equivalent is the loadlibrary/callib functions). If only a C SDK is available, SWIG can autogenerate Python wrappers (require some tweking). Matlab's loadlibrary can sometimes parse C header files, but it is not always successful. Both Matlab and Python can use COM/ActiveX objects on Windows. In addition, Matlab can use Java classes, with which Python does not interface easily. On the other hand, Python can use .NET objects, if you use Microsoft's IronPython or "Python for .NET" with classic Python. Last time I checked, Matlab could not use .NET objects, but that was a year ago. Most data acquisition hardware are supplied with SDKs for C, and perhaps COM/ActiveX objects for RAD tools like Visual Basic and Delphi. Modern hardware is often supplied with .NET SDKs. LabView drivers are also commonly supplied. If none are supplied by the vendor, there are often prewritten solutions for Matlab, Python or Java available on the Internet, but you will have to search for them, or write your own. Thus, it is not generally true that it is easier to interface hardware with Matlab than Python. It depens on what SDKs you get. On the programming side, Python is a general purpose language, Matlab is designed for working with matrices easily. Array and matrix computation in Python require NumPy, which has recently been declared stable. Matlab has been stable for quite a while. Python is multi-threaded, Matlab is single-threaded. Matlab uses pass-by-value even for the largest of arrays, Python always pass references. With Python, you can program with multiple threads; with Matlab, you have everything in one thread. As Matlab only supports synchronous i/o out of the box, you cannot do anything else while Matlab's fwrite or fread functions are 'blocking' (i.e. waiting for data from hardware or writing to disk). This is Matlab's major disadvantage for data acquisition applications. Thus to make your data acquisition run smoothly and efficiently with Matlab, you must resort to writing CMEX extensions for performing asynchronous I/O or spawn off threads. Have you ever looked at overlapped i/o in the Windows API? I can guarantee that it is hundred times more complex than anything a hardware vendor can throw at you. Alternatively, you can code the i/o in Java, and make have Matlab call Java for i/o tasks. With Python, this is a non-issue. You can put blocking i/o in separate threads or use prewritten APIs for non-blocking i/o. It is obvious which is the better option here. Generally, non-blocking i/o and multithreading is essential for any serious data acqusition application, and Matlab does not support any of these. Both Matlab and Python is interpreted languages. Matlab has a rudimentary JIT compiler, whilst classic Python is interpreted only. Microsoft's IronPython uses the .NET JIT compiler. Jython uses Java's JIT compiler (run the Server JVM or IBM's JDK for best performance, don't use the client JVM with hotspot). However, if you use IronPython or Jython, NumPy is out of the question. Thus, Matlab has perhaps a slight advantage here. With Python you can inline C in your Python code (e.g. using SciPy and Weave), and even inline assembly in the inlined C. Thus you can easily deal with hotspots in your Python code. You cannot do this easily with Matlab. For these reasons, my general view is that Python is better for data acquisition than Matlab. But using Python for the sake of using Python is nevertheless silly. The same holds true for Matlab. A data acquisition program ofte require fast graphics as well. For slow 2D plots, Python and Matlab perform equally well (Python requires Matplotlib). Matlab can draw 3D graphs, but not quickly. Python require VTK for this, which may be harder to use. For fast 2D or 3D graphics, i.e. DirectDraw, Direct3D or OpenGL, Python is the only game in town. DirectDraw is used by SDL, which in turn is used by PyGame. Direct3D is available though DirectPython (or COM objects or .NET objects). OpenGL is available through PyOpenGL, which has recently been redesigned to use ctypes; previously the build process for PyOpenGL used to be a nightmare. For GUI, Matlab only has rudementary capabilities. Python has several high quality GUI libraries (not counting tkinter). You can create multimedia applications with PyGame, you cannot do this easily with Matlab. E.g. do you want to play sound while you record? > It seems the answers are hard to come by on this issue. I sure would be > willing to give it a try, except that I'm getting paid to get a job > done, not to tinker around with Python and DAQ hardware. But if > tinkering around could save my project money on commercial software, > and still get it done on schedule, it would be a big win. I just don't > have confidence that it would. That you will have to figure out your self. The answer is not obvious. But for GUI, forget about tkinter. -- http://mail.python.org/mailman/listinfo/python-list