My name is Trey and I work for TI. We just got an 8473 to use to validate some of our CAN silicon. For purposes of interoperability, I've of course decided to use RP1210 to talk to your CAN adapter, but I've run into a little trouble loading the DLL. LoadLibrary always returns NULL. I've checked the paths and everything appears to be in order. Could you perhaps pull together some known good example code? It doesn't need to be clean or easy to read, it just needs to work. If I've got that I ought to be able to work backwards to figure out my problem.
I look forward to working with you to improve the RP1210 interface!
You will still need to install the NI-CAN driver to use that device. Let me know if you already had this installed.
Also, I just posted a new version of the RP1210 DLL which fixes an issue with J1939.
Thanks. I'm looking forward to your feedback on the DLL.
I had the version 2.6.2 of NI-CAN installed, but last night I upgraded to 2.6.3 and I was still seeing the same behavior. If I call getlasterror after calling loadlibrary it returns 0x7e "Module not found". I'll go ahead and download the new version of the DLL.
One thing I noticed is that if you search for NI-CAN the first one that comes up is 2.6.2. For about a week I thought that was the latest version because I didn’t see 2.6.3 in the search results a few down. You guys might want to move that link up in the search results.
It seems like you were able to load the library, since your call to getlasterror succeeds. The Module not found error indicates that you may be using the wrong CAN port number. If you open measurement and automation explorer and expand devices and interfaces, you should see an 8473 there. You will need to use that same CAN port number when you call RP1210.
Let me know if that helps.
Oh, and I will look into the "latest" NI-CAN driver problem.
Olivier, I believe you are mistaken.
LoadLibrary does not succeed. It returns NULL which by definition is a FAILURE!
You are incorrect about the module not found error. When I call load library, my application hasn’t tried to connect to the CAN adapter yet. LoadLibrary just loads the DLL into the thread’s memory. After this occurs, then one must call GetProcAddress to get the address of the function within the context of the thread. After this is done, then one can assign the function address to the function prototypes and make calls to the RP1210 functions. The CAN port number doesn’t come into play until you actually try to connect to the driver with RP1210_ClientConnect, hence its prototype is
short DLLEXPORT WINAPI RP1210_ClientConnect (
The port number I believe you are describing would be filled in the nDeviceId field when the above function is called.
So I suppose we are back to square one. The issue is that I cannot find/load your library. Given that I have copies of the DLL in every location imaginable, I find it hard to believe that it’s actually having trouble finding the DLL. Instead there is either a a)problem with my computer, b) problem with my application, c) problem with DLL. Can you please provide me with a small sample application that simply connects to the adapter? I know you guys already have one somewhere. It doesn’t have to be clean or pretty and I promise I won’t redistribute it. This will help be eliminate b) as a problem and in the mean time I’ll try this on another computer so that I can eliminate possibility a).
Thanks for the help Olivier,
I was able to get the example running, but I'm still working on getting my code running. I see you found the Dearborn group code...
Thanks for the example it really helped, I'll leave some more feedback once I really dig into the DLL.
I've thrown together an example application to test the DLL, and I think I've found my first bug. I'm calling RP1210_ReadMessage and this function always seems to return true. The application I've written simply spies on the CAN bus and prints any messages it receives. To achieve this I poll the ReadMessage function and look for its return value to be non-zero; this is how I know I have RX'ed data. Currently I'm sending the adapter a single message of known value. When I call ReadMessage the first time, it returns the correct value as well as writes the buffer with the data values from the message. On subsequent calls to ReadMessage (i.e. when I'm looking for new data), it continues to return the same value as well as write the same values to the buffer. I don't own a copy of the API spec, but from looking at other example code it appears that this behavior is incorrect. Can you confirm this?