About alternatives to Matlab
rpurser at mathworks.com
Mon Nov 27 16:16:54 CET 2006
I'm not going to touch the big picture issues here -- you need to pick the
right tool for the job you're doing, and only you know what works best for
your task. However, since it didn't come up, I feel I need to add a piece
of info to the mix, since I spend my days getting MATLAB working with data
acquisition hardware. To be clear, I'm the development lead for Data
Acquisition Toolbox, which is MathWorks' add on product to MATLAB and
Simulink to handle all the issues associated with interfacing data
acquisition hardware without all the CMEX work, threading, DLLs, etc. As
Sturla points out, that's not trivial work in any language.
Anyway, I just wanted to call your attention to Data Acquisition Toolbox:
I'm not sure what hardware you're using, Phil, so I can't say whether we
support it. We do add support for new hardware all the time, so I'd be
interested in hearing about your application.
All the best,
Senior Team Lead, Connectivity Products
rob.purser at mathworks.com
"sturlamolden" <sturlamolden at yahoo.no> wrote in message
news:1164504562.834005.197830 at l39g2000cwd.googlegroups.com...
> 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
> 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.
More information about the Python-list