NIDAQmx base on linux - about to give up

[WM_John_Weeks]

Alan- I know you're not from NI, but I'm going to use your post as an anchor point for my observations.

I agree with the OP that DAQmx Base was oversold. I understand that DAQmx Base was written in Labview using the Hardware DDK, and that makes it easy to port to any platform supported by Labview. But it was touted by NI as the solution to the lack of NI-DAQmx for Linux and OS X.

That is simply not the case. The missing functionality is crucial to writing robust, flexible, commercial-quality applications. The holes in support for various functionality of various DAQ devices makes it a bit of a crap shoot whether you will be able to create an application for given hardware using that hardware's full capabilities.

I finally abandoned an effort to port my Windows application to OS X using DAQmx Base. I tell my customers that they are better off running it on Windows, something that doesn't make Macintosh users very happy 🙂 But I can blame it on NI 🙂

If you read carefully, NI did tell us that DAQmx Base is a "subset of NI-DAQmx" but the rest of the hype suggests that what's missing isn't very important.

So I am waiting for OS X to join Linux with a port of NI-DAQmx. I will be very happy when that happens!

[evren]

John I totally agree with you. i spent weeks researching nidaqmx base and labview for linux and it was not clear to me at all hjow limited nidaqmx base was. i
think NI oversold mx base.

[Malcolm]

I've seen some recent feedback on the NI forums I'd like to provide some background and ask for your specific feedback on NI-DAQmx Base.  John and evren, I certainly apologize that you feel we oversold NI-DAQmx Base.  Our goal is to tell people we have a solution for their OS and educate them about the limited features.  Many customers have sucessfully built systems with NI-DAQmx Base.

As John noted, NI-DAQmx Base provides a subset of NI-DAQmx Base functionality.  By writing the driver in LabVIEW, we gain a huge multi-platform jump and are able release a driver where there would not otherwise be a DAQ driver option.  Currently that includes Mac OS X, LabVIEW PDA (including WinCE), and LabVIEW RT for RTX.  We also have NI-DAQmx Base support on Linux and Windows, but that is mostly superseded by full NI-DAQmx.

In designing the NI-DAQmx Base subset, we tried to create a logical break in the functionality so that we mostly sacrifice ease-of-use and not device features.  Most of the missing functionality is in the property nodes (Get/set attribute in C) and polymorphic VI personalities (and related C functions) but some of it is device specific.  A good example of this is providing less Create Channel personalities.  There is no thermocouple channel type for most devices, but you can still create a thermocouple voltage channel and scale the channel separately.  Our goal is to list the supported functionality by device in the readme included with NI-DAQmx Base.  Given the multifunction nature of DAQ, we certainly missed some of the use cases and features.  In subsequent releases, we've either added the missing feature, or documented it's absence.  If you need a feature that is missing and/or undocumented, please let us know.  We can only fix things we know are wrong.

The best option for feedback is the Product Feedback center on ni.com.  Go to http://sine.ni.com/apps/utf8/nicc.call_me and click on the Product Feedback link.  This information is sent to R&D and marketing.  Please be as specific as possible in you feedback.   General statements that NI-DAQmx Base doesn't meet your needs won't necessarily help us improve the product.

On the Mac specifically, we have created a support survey so please visit that survey if you have Mac specific feedback.  Visit ni.com/mac and click on the "Support Survey for Mac OS X" link.  This is great place to let us know what else you would like (including a full version of NI-DAQmx).  We are using data from this survey to help make product roadmap solutions.

Best Regards,

Malcolm Borgendale
Measurements Software Group Manager
National Instruments
malcolm.borgendale@ni.com

[WM_John_Weeks]

Malcolm:

I appreciate your concern, and I'm sorry to be so harsh about this. In general I find NI to be an excellent company to deal with (all the more surprising for the size of the company). The high expectations that I have from my experience with NI contributed to my disappointment with DAQmx Base.

In regard to being up-front about what's in DAQmx Base, I looked at the current web page about DAQmx Base (http://sine.ni.com/nips/cds/view/p/lang/en/nid/14480) and find the situation much improved. Thank you.

Initially I was told (or understood- it's getting to be a while back and my memory is fading) that there was no access to properties, but that mxbaseconfig allowed a user to configure a task that included most of what's missing by not having properties. I was prepared to allow my customers to configure a task which I would load.

M-series devices weren't supported by mxbaseconfig in version 1.5.

Having loaded a task, I need information about the task in order to connect it properly with the host application. That requires properties.

I was sunk.

So- what I really need is a port of NI-DAQmx to OS X.

Thank you for listening!

[evren]

Sorry if i repeat myself.
I don't care at all about the polymorphic DAQ VIs or the thermocouple type channel setup things.  At the begining of this thread I statred to mention the problems i was having. I have Windows LV programs that do AO and AI simulatneously. I could not easily get those two processes to start synchronously. Pretty much every single DAQ vi in my program would have had to be replaced with NIDAQmx base programs to run in base. It just became too cumbersome to convert the whole program, especially if NIDAQmx full was going to come out in a couple of months, i preferred just to wait and port my program to linux with NIDAQmx. The main reason I'm upset is that NIDAQmx full only works with LV 8 on linux and I stuck here with LV 7.1. I'm angry that I have to now pay to  upgrade to LV8 just to have my linux version do what LV 7.1 on windows can already do? I feel like i'm being forced to pay twice. I can't even see the point of putting NIDAQmx base out there if NIDAQmx Full is going to come out. It just makes no sense to me.

In any case, thanks for your consideration.

[bradj0]

This scenario is similar to what I experienced when upgrading from LV 6 to LV 7 for Mac OSX about 1.5 years ago. I put an order in for about $60k in DAQ equipment and decided to also order LV 7.0 because it was compatible with, at the time new, Mac OS X. I spoke to a rep and verified that everything would work fine. I get everything in, install LV 7 and a DAQ board and go to install NI-DAQ only to have it report that it is not compatible with OSX. LV7 will work on OS9 OR OSX, but the traditional NI-DAQ drivers only works under OS9. I received a very polite reply from NI but I am still out the $$ for buying 7.0. Futhermore, the 'new' NI-DAQ/LV7 under OS9 has deep-level bugs that causes ~45 seconds freezes of LV. I have since gone back to just using LV6.

Now I am reading the forum because I finally decided to try the DAQmx base for OSX. Today I installed a DAQ card and 7.0 on a new OSX machine. I am already frustrated by DAQmx base, more post forthcoming if I cant find answers to my questions buried in the forum. The html help files that came with the distribution are 100% WORTHLESS. I *NEVER* buy programming books and I spent 1-2 hrs today searching the web for a book of NI-DAQmx (base)... I found nothing. I want answers to esoteric, very specific, long-term behavior questions. There is so little functionality in the DAQmx base VIs. For example, if you start a continuous analog acq, there is no obvious way to query the buffer state.. if anyone remembers "AI continuous acquistion.vi" where every call of the VI also returns the number of remaining FIFO samples. I typically sample as fast as possible and my while loops cannot keep up so the buffer fills. The 'old' way to prevent buffer overrun is to grab all the samples (and average, and you also have access to the acq timestamp). How is any of this possible in DAQmx base? At this point, I see myself having to manually adjusting the "# of samples" until I find a balance and my VI doesnt crash. My ACQs usually run for DAYS if not WEEKS, streaming to disk, etc, etc. I spent a fair amount of time modifying the traditional NI-DAQ VIs and now I'm back to the beginning.

When I read this thread I immediate thought of my own past experience upgrading from 6 to 7 and how it is being repeated with LV8 and NI-DAQmx. I had to upgrade to LV7 to be native in OS X, but it couldnt do DAQ... and then a year later I finally get DAQmx base that gives me a crippled DAQmx base. The only reason why I use LV is for DAQ-- otherwise I use Matlab. Like the other user, I ONLY use LV for DAQ, I have no other use for it. If it doesnt do DAQ, it isnt worth anything me. My LV7 has sat UNUSED pretty much since the day I bought it.

If and when the full NI-DAQmx is available for OSX, will it require LV8? Will I be forced to buy LV8 to FINALLY get full DAQ support in OSX? Will NI refund the purchase of LV7, considering it really does not live up to its purpose. It sounds like the linux NI-DAQmx (full) requires LV8... I anticipate NI would make the same decisions for OSX too. The only reason why I am now trying to upgrade to LV OSX is so I can use this computer for other development tools that require OSX. If I will have to buy LV8 to get full NI-DAQmx functionally... I think I'll just ditch this effort and go back to a clean OS9/LV6 install. At this point, I have spent more money and TIME trying to get LV7 to work on OSX than buying a brand new OSX machine for my other development tools.

Part of the reason I have chose NI in the past, over the cheaper competitors, is I expect a fully integrated development environment. When I buy NI LV and a NI-DAQ it SHOULD WORK.

Brad

[bradj0]

After reading Malcom's comments "Our goal is to tell people we have a solution for their OS and educate them about the limited features," and pursuing trying to learn more about daqmx base, I came across the following URL:
http://www.ni.com/mac/daq.htm

That is the URL direct for a description of DAQ on OSX. I suggest you read the entire content of the page but I quote:
"NI-DAQmx Base driver software offers a programming interface similar to NI-DAQmx driver software as well as increased ease of use in connecting with high-performance NI data acquisition hardware. NI-DAQmx Base provides a clean, concise programming interface; programmatic channel and task creation; and other features previously available only with NI-DAQmx for Windows."

I don't see any wordage there backing up Malcom's claim that NI tried to "educate them about the limited features.' In fact, when I read that page it sounds like NI-DAQmx base is SUPERIOR to NI-DAQmx, eg "as well as INCREASED ease of use...."

I know that is just a marketing blurb... but someone shouldn't have to spend 10 hours reading the NI forum to figure out that the product that is currently on a UPS/FedEx truck only has "limited feature" DAQ driver support. I appreciate that NI is trying to deliver functionality to users. However, when purchasing decisions are made based on the above statements, there are obvious problems. If I was a new NI puchaser and wanted to use a MAC and just came along and said WOW it will work, I'll buy it, look it says it right there on the website. Well, that is great and all, but the better thing would have been for me to buy all the right PC hardware/software. Seriously, put a big RED BOLD warning:
"WARNING, DAQ FUNCTIONALITY ON OSX IS LIMITED COMPARED TO WINDOWS PLATFORM. PLEASE CONSIDER PURCHASING WINDOWS HARDWARE/SOFTWARE IF POSSIBLE. If you REALLY want OSX software/hardware, PLEASE go to our forum section (URL HERE) to see if other MAC users feel your tasks will work with NI-DAQmx Base. We are striving to get full functionality on the MAC/OSX platform because, well MACS RULE, but in the mean time, if you can, use Windows."


Brad

[sth]

> I want answers to esoteric, very specific, long-term behavior
> questions. There is so little functionality in the DAQmx base VIs. For
> example, if you start a continuous analog acq, there is no obvious way to
> query the buffer state.. if anyone remembers "AI continuous acquistion.vi"
> where every call of the VI also returns the number of remaining FIFO samples.
> I typically sample as fast as possible and my while loops cannot keep up so
> the buffer fills. The 'old' way to prevent buffer overrun is to grab all the
> samples (and average, and you also have access to the acq timestamp). How is
> any of this possible in DAQmx base?

Start by peaking inside the Read VI. You will find that the actual part that retrieves data also returns the number of remaining samples! Now just modify the VIs so that this value is actually passed back to the caller and you are done! Of course you will now have a non-standard NI-DAQmx base installation but that seems to be what has to be done to make it work.

All in all, NI-DAQmx Base has severe flaws. There is much that is not possible by DESIGN. This is not a lack of resources or testing, but just cutting corners when setting up the system. It seems that it was not thought out very well before coding in terms of what the eventual usage would be.

> At this point, I see myself having to
> manually adjusting the "# of samples" until I find a balance and my VI doesnt
> crash.
This is insane. And is the same problem I ran up against. I tried a repeated finite acquisition but found that did not work:
<>
The best suggestion from NI is a continuous read from buffer but

A continuous read will crash when the buffer fills and it overwrites leading to necessarily reallocate the DMA buffer and restart the acquisition. This needs to be fixed.....

I hope someone is still reading this thread.....

[WM_John_Weeks]

> I hope someone is still reading this thread

Well, my activity on the forum has dropped to almost zero since my development cycle has gone to other projects for the time being. But I got an e-mail today that there was a posting to this thread...

As a sop to our customers who really, really want to do data acquisition using their Macintoshes, I had created a simple plug-in for our application (Igor Pro) that does nothing more than allow them to program using the functions available in NI-DAQmx Base.

Then a new version of mx Base came out.

The old plug-in won't work with the new driver. A new plug-in built against the new driver, won't run with the old driver. So I can't ship one version for everyone. This was on top of some compatibility problems caused by having an instance of Labview running as part of our process.

I have pulled the plug-in from our shipping application.


This is very frustrating coming from a company for which I have a very high regard, as I mentioned in a previous posting on this thread.