About alternatives to Matlab

[Rob Purser]

Hi all,

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:
http://www.mathworks.com/products/daq/

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,
-Rob

-- 
Rob Purser
Senior Team Lead, Connectivity Products
The MathWorks
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
>> 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.
>