NI-KAL for 2.6.31+ Kernels

[mhoogend]

That's simple, if you can reach more users, probability to sell software/hardware to them is higher. The question is if the complexity of this task will pay back, which leads to the next question: Are open source drivers cheaper than proprietary ones?

If only it were as simple as open source drivers being cheaper than proprietary.  For return on investment there is how much you invest, and how much money you make.  A company wants to make the most profit for where they invest their time.  With limited man power there is still the question of will I get more return on investment on Linux or on other products.

What about unlimited man power is it that simple then?  If the money you earn is still near 0, then investing any time is not worth it.  Now assuming there is money in it, which obviously there is some based on the interest in this thread, there are other considerations.  Others have posed the question of essentially risk to the business by exposing how things work under the hood.  There is varying opinion on this, but I will guarantee you that any closed source software has investments that a corporation would like to protect since they paid for their development.

First, this a chicken and egg problem. There are no customers for non existing products. The question is, how much is the market share and how large will/may it be in the future.

Fully agree on it is most important what the market share looks like.  But the market most important to NI is the customers in our target markets.  Some of those markets are getting some rumblings of Linux but that has continued to be an exception rather than a trend.  A company is still going to go where it knows it can find money.  In particular in tight times of recession (like the last year) companies will focus on where they can make the most money and avoid additional risk.

I used comedi (and other open source software) many years ago. The problem is, that we live in a heterogeneous world and applications need to be portable between platforms. E.g., if I use function A in LabView, it must be available on other platforms too. Comedi/Lib does not implement the proper cross platform capable interface to LabView so I switched to nidaqmx/base when it was available. Writing an application on one platfrom and letting it run on others (e.g. different processor/architecture, 64-bit support and endianes come into mind) without modifications is a major advantage of linux, which can only be fulfilled with open source drivers.

I'm actually a little confused on this paragraph.  So first you decided to go away from Comedi (open source) because it doesn't operate with LabVIEW and LabVIEW is important so you can be portable across platforms, but then open source is the only way to fulfill portability?

I think the main thing here is that if you want portability with Linux in the picture then open source is a needed ingredient.  So perhaps a solution would be making Comedi operate with LabVIEW and support your boards on Linux, and allow your LabVIEW application to run on Windows or some other platform as well?

[jchrisj]

My needs are maybe a little more pragmatic. I need to run Linux because of security issues. It may make no sense to anybody but running Windows on a network-connected data acquisition or control computer is basically a non-starter. There are a number of mandatory security settings for Windows machines that have a history of breaking their ability to actually run the instrument that they are connected to.

I have been running 32 bit OpenSuSE 10.3 quite happily but since that is now out of support its days on our network are numbered.

What I need from NI is a version of LabVIEW that works with currently supported Linux distributions. I am much less sensitive to the whole "tainted kernel"  issue. I can see the advantages of moving the proprietary stuff to user space, but in the end I just need something that works.

Chris

[marvin24]

I definitely hope that they will drop the proprietary kernel stuff. On the other hand, I think they can't do this anymore as there are customers who bought devices/drivers from NI. If they decide to drop support for it, serveral customers will be very p... off. This is the trap I was talking about earlier. And NI is also to late to indroduce a new, open-source driver interface for their hardware. There is already comedi in the staging part of the kernel and kernel developers will not accept a second one. So the only long term solution is to start contributing to comedi/kernel and add LabVIEW support at least for their hardware.

[rolfk]

If comedi is designed in any meaningful way, then adding support for NI cards to the user interface of it to be accessed with LabVIEW would automatically add support for any other comedi supported hardware. Not exactly what NI is out there to do of course, but oh well.

Sorry that I can't make more detailed comments about comedi. Last time I looked at it is several years ago, and back then it was the typical gobble of various driver components with various ways of implementations, glued together in various ways that made it a bit of a miracle that it could be made to work at all with more than one single low level driver at the same time.

If it is indeed considered for inclusion into the kernel, as you say, it must certainly have made some serious progression from that.

[Shawn B.]

marvin24 wrote:

I definitely hope that they will drop the proprietary kernel stuff. On the other hand, I think they can't do this anymore as there are customers who bought devices/drivers from NI. If they decide to drop support for it, serveral customers will be very p... off. This is the trap I was talking about earlier. And NI is also to late to indroduce a new, open-source driver interface for their hardware. There is already comedi in the staging part of the kernel and kernel developers will not accept a second one. So the only long term solution is to start contributing to comedi/kernel and add LabVIEW support at least for their hardware.

NI could still drop the proprietary kernel stuff as long as there was an open source kernel driver that provides the features needed by the current Linux customers.  Also keep in mind that the majority of users use an API like NI-DAQmx or comedilib, and do not rely on a kernel API.  This means that it is theoretically possible to create a proprietary NI-DAQmx-like API that calls into the open source Comedi kernel driver.  However, this is only in theory since the current open source Comedi drivers do not support all of the features that would be needed for a NI-DAQmx-like API.  So yes, if NI wants to move in this direction then they need to exactly what you suggest and start contributing to the Comedi kernel piece so all of the needed features are there when it moves out of the "staging" folder of the kernel.

Shawn Bohrer

(No longer works for NI)

[ShermanO]

I am bumping the topic because I too am needing some sort of support but for a different reason.

I am an embedded programmer and my platform of choice is Fedora 10,11, 12

I recently started using ELO touch screens instead of EIE. I had to upgrade from Fedora 10 to 12 for the Touch screen drivers and now am not able to use the drivers for the USB 6009 that is such a sweet heart for small embedded projects.

I contacted NI about getting the register mapping and such information so I could write an embedded driver for the 6009/6008. I was told that the information was proprietary and could not have it.

I'm willing to port the NIKal drive to the new kernels. I have just went through the kernel patching with no success and would really love to be able to continue using these 6008/6009 devices. I would prefer to be able to talk directly to them and bypass the C/C++ API but am willing to compromise.

More than likely I'll build a debug Fedora 10 kernel and use kernel and module debugging to log the transactions to the USB device and start clean by reproducing the transactions without NIKAL. If anyone has experience with the LABView side of the interface I could use the help. Else it will only be a C/C++ API version which is all I require currently.

I'll keep you posted.

[mhoogend]

If you are successful in your endeavors to create a C driver for the USB-6009 through reverse engineering, it seems like it would be a useful contribution to the Comedi project (http://www.comedi.org/).  That driver is in the staging tree for the kernel and depends on community support for adding new hardware support.  I only saw 2 USB devices supported by a quick search, but you could probably expand on that.  That would also give you something to fit in with and maybe flesh things out a little bit to give you direction?

From the NI side, to support the 2.6.31 kernel with NI-KAL and drivers supported by it, we'll certainly be letting the community know as soon as we have something new for everybody.

[luca72]

please confirm now if i need to use gipb under linux i can't under kernel 2.6.31, is this correct?

With witch kernel i can use it?

Thanks

Luca

[mhoogend]

And actually coming back to this, I'm not sure why this slipped my mind, but have you tried to get the USB-6009 to work?  You would probably have to do extra steps, but theoretically you could do it since the USB support for that device is from user-mode and technically doesn't have to work with the kernel modules such as NI-KAL.  I haven't ever heard of anybody figuring out the steps to do so, but it seems like you could.  Especially if you are savvy enough to start looking at programming the device yourself you could probably figure out if it is possible to just have the user-mode side loaded and not have to worry about kernel-mode pieces.

If you do get that up and running you could also post the steps in a document in this community.  The question has come up before.

[mhoogend]

please confirm now if i need to use gipb under linux i can't under kernel 2.6.31, is this correct?

Correct, it will not work.

With witch kernel i can use it?

You should be successful with a 2.6.28 or earlier kernel.  If your distribution version doesn't have an older version prepackaged you can download it from kernel.org.