Phil Schmidt wrote: > Thanks for that list. I'm currently in the process of getting quotes > for a bunch of Matlab tools for hardware-in-the-loop simulation. Big > bucks.
Yup, and better spent elsewhere... > I'd love to use Python, but I'm not comfortable with the hardware side > of that. I'm certain that most, if not all data acquisition hardware > comes with DLL drivers, which I could interface with using ctypes. I'm > concerned though about spending more time messing around with the > hardware interface than it's worth. Usually you have to mess equally much with Matlab, writing CMEX interfaces between the DLLs and Matlab. And afterwards you get the headache of Matlab's single-threaded environment and horrible pass-by-value sematics. > Do you have any experience with this side of the Matlab replacement > question? How about anyone else? Any recommendations? If you are afraid of doing some C coding or using ctypes, I'd say go for LabView. When it comes to data acquisition, LabView is far superior to Matlab. And data acquisition hardware usually comes with LabView drivers ready to run. LabView can also compile programs that you can run on real-time OS'es and common DSP chips, so you will not need to port your code to these targets if you need hard real-time constraints in your system. First find out what drivers or APIs are supplied with the hardware. Then do the decision of which language to use - including Python, Matlab, LabView, Java, C# .NET, C or C++. I would in any case get a quote for LabView as well, i does not cost you anything just to obtain the quote. Generally, development time is far more expensive than licenses, even with the ultra-expensive Matlab and LabView software. Using Python just for the sake of using Python is silly. -- http://mail.python.org/mailman/listinfo/python-list
