Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

Linux I/O Drivers for LabVIEW

I understand that DAQmx is not open source, however, what I am trying to understand is what is the difference between NI-KAL and NI-DAQmx?

As far as I have understood, NI-KAL is a low level kernel driver and the NI-DAQmx is the user space C API (a.k.a C glue code) that sits between NI-KAL and LabVIEW drivers? Am I correct?

0 Kudos
Message 11 of 22
(1,065 Views)

KAL is Kernel Abstraction Layer. This is in fact mostly a kernel driver that abstracts anything kernel related in a way, that the drivers that are above it can mostly use the same code base independant of the actual platform. So this driver handles the actual management of kernel memory, DMA, interrupt service configuration and handling, etc. On top of that there is usually another kernel driver that is specific to your type of hardware. The KAL driver had to be open sourced since the Linux kernel developers have defined various kernel APIs that a closed source driver may not call anymore without violating the GNU license.

Theoretically one could write one single generic KAL type driver and call it then from user space libraries. However such a driver would need to be very involved, since you do not want to do a kernel driver call for every register address access when setting up hardware. Every translation from user space to kernel space is rather expensive in time, and if you need to program lets say 100 registers to prepare a certain operation, that would be very expensive if you would do it from user space and use one KAL driver call per register.

Also kernel driver calls are usually not convinient to do from an application level, therefore most kernel drivers come with a user space shared library that provides a C function API and calls the kernel driver through the required OS specific device driver access method. In Windows for instance you open a kernel driver as a device and invoke FileRead(), FileWrite(), and IOControl() calls on it. Linux will be probably rather similar. While you could write VIs that call these system APIs through the Call Library Node, setting up the parameter list for IO Control in LabVIEW would be at best a huge pain in the a$$ and most likely not possible for most of the calls.

Not to forget that you would have to do all the work again for every other application you write, such as Visual Basic, Python, LabVIEW, etc and each time use the environment specific methods to implement this. So there it's much easier to do the involved kernel driver access once in a C shared library and then call a much easier to use C API from all those environments.

Rolf Kalbermatter
My Blog
0 Kudos
Message 12 of 22
(1,065 Views)

KAL is not a driver per se. It's more of a framework on top of which our drivers are built. It abstracts the kernel differences between various platforms. We write as much of the platform-specific stuff as we can in the KAL layer (reimplementing it for each platform), and that exposes a unified API and driver architecture across all platforms. Then we build our specific drivers on top of that. Those drivers still have a kernel component and a separate user mode component. DAQmx, then, is still multiple componets: a kernel part, a common user mode part, and then a separate component still that sits between LabVIEW and the common user mode part.

DAQmxBase, by the way, is a totally separate driver which is built in LabVIEW itself using the VISA API. The DLL you use for DAQmxBase in a C application is actually a LV-built DLL (that is, a DLL written in LabVIEW). That may still be an option for you.

0 Kudos
Message 13 of 22
(1,067 Views)

Not sure what you mean by "single generic KAL type driver"?

And last but not th least, regarding your comment about platform independent (Windows, Linux, etc.) code, what is the best way to ensure that we have to do minimal work (code re-write) when we port, say for example, Linux LabVIEW stuff (kernel drivers, user space shared library, LabVIEW VIs library) to Windows? Is there a document explaining porting from Linux to Windows?

0 Kudos
Message 14 of 22
(1,067 Views)

Aside from a file name it's not "called" anything. From a user's perspective it doesn't exist. There's just the API, which is DAQmx. If you ask "is DAQmx user mode or kernel mode" then the answer is "yes". It's both. Don't think of DAQmx as a single component or a single file. It's the whole stack. It's just layered. That's how drivers typically work.

What I meant about NI-KAL is that it is not a driver. It's not for a specific device. It's not even for a specific driver. It's a shared component on top of which other drivers sit. Any kernel mode components of any driver from NI is probably going to sit on top of NI-KAL.

"And last but not th least, regarding your comment about platform independent (Windows, Linux, etc.) code, what is the best way to ensure that we have to do minimal work (code re-write) when we port, say for example, Linux LabVIEW stuff (kernel drivers, user space shared library, LabVIEW VIs library) to Windows?"

If you're porting C code you're on your own. We obviously aren't in the business of helping people port C code across platforms. We have a cross-platform development tool (LabVIEW) which we maintain so that users can write their code using our tool and not have to worry as much about platform differences. We handle those differences so you don't have to. If you're working outside our tool then you have to do all the stuff we have to do, and you're pretty much on your own to figure that stuff out.

We can help you figure out how to integrate with LabVIEW, but that's not going to vary much across platforms. Doing a kernel driver, though, will be totally different on Linux than on Windows, and this is not the proper forum to figure out how to write cross platform kernel drivers.

0 Kudos
Message 15 of 22
(1,067 Views)

Understood about DAQmx, that confusion is now clear!

AdamKemp wrote:

If you're porting C code you're on your own. We obviously aren't in the business of helping people port C code across platforms. We have a cross-platform development tool (LabVIEW) which we maintain so that users can write their code using our tool and not have to worry as much about platform differences. We handle those differences so you don't have to. If you're working outside our tool then you have to do all the stuff we have to do, and you're pretty much on your own to figure that stuff out.

OK, I completely understand that NI cannot help with writing cross-platform kernel drivers, which is totally fine. Also I understand porting of VIs based on this article.

All I need to figure out now is to how can the user-space shared library (C function APIs) porting problem can be avoided if we use NI's corss-platform development tool (LabVIEW)? Based on the above discussions, I always thought that these C function APIs are a "requirement" and is outside the LabVIEW tool. For what you are saying, it seems that one can avoid (get away with) writing these C function APIs (that sits between the LabVIEW and user mode part of the device driver), if we use the LabVIEW tool. Did I understood that correctly?

Also, how does the Call Library Function Node (CLFN) fits in this picture overall? It seems that if your VIs uses CLFN than they may or may not be portable. How can one avoid using CLFNs?

0 Kudos
Message 16 of 22
(1,067 Views)

You may want to read through these 3 posts by me at http://expressionflow.com/author/rolfk/. They should give you an answer to how to make your C API such that you do not have problems to port a VI library accessing this through CLFNs. And you can not really avoid using CLFNs if you want to access your own hardware.

Rolf Kalbermatter
My Blog
0 Kudos
Message 17 of 22
(1,067 Views)

Some drivers don't require a kernel component. Some can even be written entirely using the VISA API primitives available in LabVIEW. If your hardware allows for that (don't ask me what's required, because I'm not a harcdware person, so I honestly don't know) then you don't need a kernel component or a C DLL. You can just write your whole driver in LabVIEW. That is what DAQmxBase is. It's a driver written in LabVIEW. There is no C DLL under it. It's just LabVIEW code.

If for whatever reason you can't do that (again, I don't know enough to tell you what the requirements are) then you may have to write a C DLL and you may also have to write a kernel component under that. At that point a lot of driver developers would prefer to have a C driver usable outside of LabVIEW (and with an API that works well for C) and then build a LabVIEW driver on top of that. For that to work well you usually want to insert yet another layer between your normal C driver and your LabVIEW code, which is that extra DLL. So a complete stack might look like this:

  • User's LabVIEW code
  • Your LabVIEW Driver
  • Your LabVIEW-C driver glue DLL (called via Call Library Node)
  • Your normal C driver DLL
  • Your driver's kernel component

The top 3 layers can be entirely portable if you do it right, but the normal C driver may have to be very different under the hood on each platform, and obviously the bottom layer will very different on each platform. DAQmx tries to reduce those cross-platform issues by doing this:

  • User's LabVIEW code
  • DAQmx LabVIEW driver
  • DAQmx-C driver glue DLL (nilvaiu.dll)
  • DAQmx C driver
  • DAQmx kernel component
  • NI-KAL

The bottom two layers are kernel mode components, but we pushed the platform specific stuff down into NI-KAL so that the rest of the kernel component wouldn't have to change as much. Writing NI-KAL is non-trivial, though. It's a big undertaking to understand driver architectures on multiple platforms and write an abstraction layer for them. It may not be worth it for you. Basically, the fewer of those layers you have to write the better.

I have to say at this point that I am not a driver developer. This about the extent of my knowledge of drivers, and if you need more help figuring out how to architect a driver then you should really find a more appropriate forum. I really don't have much more information to give you at this point.

0 Kudos
Message 18 of 22
(1,067 Views)

AdamKemp wrote:

So a complete stack might look like this:

  • User's LabVIEW code
  • Your LabVIEW Driver
  • Your LabVIEW-C driver glue DLL (called via Call Library Node)
  • Your normal C driver DLL
  • Your driver's kernel component

That's what I was looking for i.e. a completel overview of the stack from OS to application level!

Is this stack model true for Linux too? In particular, do we need the Linux equivalent of the component "Your normal C driver DLL"? In other words,  can the "C driver glue code" directly talk to the Linux kernel driver component?

I really appreciate your help and explanation so far! You guys are awesome!

0 Kudos
Message 19 of 22
(1,067 Views)

"Is this stack model true for Linux too?"

I think so, but the DAQmx driver on Linux hasn't been revved in years as far as I know. There's only DAQmxBase, which is totally different (built in LabVIEW directly).

"can the "C driver glue code" directly talk to the Linux kernel driver component?"

It can. That makes sense if you only ever plan on supporting LabVIEW clients. If you want to support C clients then it makes more sense to build the LabVIEW support into a separate layer. That's why we do it.

0 Kudos
Message 20 of 22
(1,067 Views)