Industrial Communications

cancel
Showing results for 
Search instead for 
Did you mean: 

Can we get a .NET API for NI-CAN?

In the day and age where most programmers are using object-oriented programming, I find it surprising that NI-CAN does not have a .NET API. I'm building a tester that has almost all NI equipment, the vast majority of which has .NET interfaces as well as LabView drivers, but it looks like I'm going to be stuck using another vendor's CAN interface because I want to program in C#.NET. How about at least a binding to the C DLLs for us non-LabView people (which I realize is a band-aid but better than nothing)? I realize that not every piece of hardware can have a driver for every single programming environment, but CAN is a pretty important interface and I suspect that other people have asked/will ask for this.

0 Kudos
Message 1 of 11
(8,045 Views)

Hi mdbeaster,

 

I'm sorry about your inconvenience.  Unfortunately, as you are aware, there is no .NET API for NI-CAN.  

 

Some of our customers have posted C# wrappers for NI-CAN in other forum threads such as this one: http://forums.ni.com/t5/Automotive-and-Embedded-Networks/C-Wrapper-for-NI-CAN/m-p/975776#M4509. 

 

Additionally, this Knowledge Base article states that you can use the Visual Basic Upgrade Wizard to convert the existing Visual Basic API for use in .NET: http://digital.ni.com/public.nsf/websearch/FF00FD7D7A77EB038625712A004FC52F?OpenDocument.  

 

Finally, please feel free to submit a product suggestion: http://digital.ni.com/applications/psc.nsf/default?openform

 

I hope this helps!

 

Regards,

 

Dayna P.

Applications Engineer

National Instruments

0 Kudos
Message 2 of 11
(8,034 Views)

Sorry for necro'ing this thread, but my experience with this issue has been frustrating to say the least.  I'm really shocked that after all these years, and given the popularity of .Net as the go-to platform (as it has been for years also) for windows gui development, in particular c#.

 

That said, I've spent days trying to build a c# interface for the NI-CAN library.  I actually have made quite a lot of progress, having successfully set config parameters, opened the interface, and even written a frame, as evidenced by the bus monitor running on another computer with its own CAN module.  The problem I'm having now is with reading frames.  As others may have encountered, the biggest problem with interfacing with the ni-can dll is memory management.  You have to write a lot of "unsafe" code and get into unmanaged memory, stack allocation, etc. in order to interface with the c++ dll and how it's handling buffers, etc.  This is a problem with C# and .Net in general.  I've written several work-arounds and gotten into some scary memory manipulation code, but ultimately things have started falling apart.  When I read frames in, I can actually read the first frame and extract the important info like Arbitration ID and the data bytes.  After that first frame though, the frame data starts getting jumbled, probably because I'm missing some mathematical manipulation of memory pointers, etc.

 

Long story short, I'm almost at my wits end with this, even though I've come really far.  So I'd like to ask the community -- given that it's been a few years since the last post I could find on this topic -- if anyone has successfully developed a c# interface to the NI-CAN Frame API.

 

Thanks!

0 Kudos
Message 3 of 11
(6,751 Views)

As the OP, I'll try to answer as best I can, even though NI hasn't done much to make me happy of late.

 

Are you actually using older hardware that requires the older [essentially deprecated] NI-CAN API, or are you using the more modern NI-XNET API? It might be a moot point since neither actually have true .NET interfaces, but I abandoned the NI-CAN idea shortly after my original posting in favor of NI-XNET. My hardware is the PX-8512/2. It's still an incredibly painful interface to work with when all you want to do is pass raw frames back and forth, but I did eventually get it working. I could share some of that with you, but it'll likely be useless if you're using NI-CAN.

0 Kudos
Message 4 of 11
(6,747 Views)

I'm using the USB-8473 for this application.  I have a PXI box with the PXI-8461 in it, but am just using that for bus monitoring right now.

 

Actually I'm surprised at how far I've come in the past 2 days.  I had never attempted to interface with a non .Net dll before, so this has been more of a learning effort than anything.  If I can overcome this issue of getting the readMult function to give me properly aligned data, I'll be all set, because I am actually receiving exactly as many frames as I'm expecting, and I can see when I load a text box with all the raw bytes, the data I want is definitely there, so I'm in the home stretch.  My problem has mostly to do with pointing to an array of structs (i.e., an array of CAN frames) and it appears that each struct is padded or offset somehow, because each new ArbID is offset by  a few bytes, and therefore all my data bytes are offset. really strange, but like i said, this is huge progress over a few days ago.

 

At least one benefit of all this is I'm much better armed with knowledge I'll need to interface with non .Net dll's in the future.

 

 

0 Kudos
Message 5 of 11
(6,742 Views)

Yes, there is a bit of a learning curve associated with PInvoking unmanaged DLLs, but you are better for having learned it! Wish I could be more help but as I mentioned, everything I've done has been with NI-XNET. If you ever upgrade your hardware and need some help with the .NET integration, let me know.

0 Kudos
Message 6 of 11
(6,739 Views)

Thanks, I appreciate it!

0 Kudos
Message 7 of 11
(6,735 Views)

Just to let you know, I just got the C# interface working.  Once I figured out all this managed vs. unmanaged memory business, I did some digging and found out that the c++ api (or the CAN module itself) was messing around with endianness on the received frames.  Passing an ArbID to the API for a CAN write via the frame struct was handled fine because I assume the API internally flips the ArbID word around.  Coming back on the receive side, the ArbID (along with the timestamp and other parameters) seemed to be out of order.  I finally decided to replace the whole CAN frame struct with my own struct of 22 individual bytes.  I then changed the order of the ArbID bytes on the received frames and voila: I'm receiving perfectly formatted CAN frames with all data matching what my bus monitor app is showing.Took me 2 days doing all this from scratch, but I'm proud to say I accomplished what it seems that few others have been able to do.  🙂

0 Kudos
Message 8 of 11
(6,720 Views)

 David, That's impressive. I've only just found out that there is no C# wrapper for NI-CAN. The rest of my application is in C# and I need to get some info from devices on a CAN Bus. I'm also using the NI USB-8473, but I haven't dealt with CAN before. Can you share your wrapper classes?

0 Kudos
Message 9 of 11
(6,418 Views)

I'd be happy to help, but would prefer we discuss offline.  As much as I'd love to give away what I came up with, it was actually quite a lot of work and at the same time is really tailored to my particular application.

 

Anyone who might need help with the .NET wrapper for C# for the NI-CAN drivers can contact me at dluberger@gmail.com and be sure to give me an idea of what you're trying to do specifically.

0 Kudos
Message 10 of 11
(6,411 Views)