RP1210 (CAN and J1939) Support for NI USB-CAN

[O_Proulx]

Hi Trey,

This was a bug in an earlier version of the DLL. The latest version

should have that fixed. Can you please re-install using the latest

version and let me know if you still see the behavior.

Thanks,

[Aliases_are_gay]

Olivier,

I put together a file which consolidates some of the helper functions used to access your RP1210 library.  I've attached it along with its header to this post.  Perhaps a cleaned up version of it could be of use to your customers.

Trey

[Aliases_are_gay]

Olivier,

I've been using your RP1210 DLL to put together a CAN Bootloader program.  I've run into a minor problem in that your DLL doesn't seem to be able to send 0 length CAN data packets.  The sendmessage call will return 0x90 (#define  ERR_INVALID_COMMAND  144) when it is called with a value of 3 for the message size parameter.  If you refer to the RP1210 spec, 3 should be the minimim size when transmitting a zero length standard ID packet.  Could you please take a look at this ASAP.  We are putting this bootloader in the ROM of a new processor and are kinda crunched for time.  I need to get my bootloader validated quickly and I need your DLL to do it.

Thanks,

Trey German

Texas Instruments

[O_Proulx]

Hi Trey,

We should support data length of 0.

The function prototype is:

hort SendCanMessage(
                     short          a_Id,
                     char          *a_MessagePtr,
                     short          a_MessageSize,
                     short          a_Blocking,
                     NCTYPE_UINT32  a_Timeout )

The ERR_INVALID_COMMAND error is thrown in 2 different cases:

1. If the a_MessagePtr is null

2. if a_MessagePtr[0] is not 0 or 1

This represents the type of ID for your CAN frame.  Valid values are 0 and 1

STANDARD_CAN                        0x00     // Filters
EXTENDED_CAN                        0x01     // Filters

A little note:

a_MessageSize is not the CAN message data length.  It is the RP1210 message size.  For a standard ID, that is 3+CAN_MSG_SIZE (1 byte for the type, 2 for the ID).  For extended IDs its 5+CAN_MSG_SIZE (1 byte for the type, 4 for the ID).

Let me know if both those cases are valid in your case, or if you think we should handle 0 length messages differently.

Thanks,

O. Proulx

[Aliases_are_gay]

I think your handling of the messages is fine and is compliant with the RP1210 spec, but I'm still having trouble.  I checked both conditions that you listed and they are both false (i.e. MessagePtr isn't null and MessagePtr[0] = 0).

Here is my CAN transmit function and variable values

You can clearly see that SendMessage is being called with a char * to 0x12fcb4 (buf) and that *(unsigned char *)0x12fcb4 = 0 (buf[0] = 0).  Also if I increase the MessageSize to 4+cnt (instead of 3+cnt), but keep the other parameters the same the call succeeds.  Am I missing something here, or do you think there could be a problem with the DLL?  I can work around not being able to send 0 length packets in the bootloader, so this isn't as pressing as I had originally stated, but I would still like to come to an understanding of what is actually going on here.

Thanks,

Trey

[O_Proulx]

Hi Trey,

I just uploaded a new version of the installer (with a new version of the DLL) that should fix this issue.  Thanks for letting us know and working with us on this one!

(Link just in case...http://decibel.ni.com/content/docs/DOC-13164)

O. Proulx

[jboden]

Hello.  Is the RP1210 support for NI-XNET devices/drivers.  We were just told that our new CAN module with CompDaq will not work with NI-CAN no longer so I wish to use RP1210 for everything so I do not need to rewrite each time.

Thanks,

Jay Boden

[somaamos]

Hi. Trying to test the RP1210 driver and running into problems (Phil B posted one here for me, I will reiterate below): https://decibel.ni.com/content/message/34597#34597

1) The ordinal values in the DLL are OK but the function names are incorrect. Our software loads the functions by name. You can see this using depends.exe, for example:

_RP1210_ClientConnect@24 should be RP1210_ClientConnect

_RP1210_ClientDisconnect@4 should be RP1210_ClientDisconnect

etc.

Perhaps a missing c_decl?

2) Depends shows a missing dependency on the MSVCR90.dll which I believe is the VC 2008 C runtime. I believe the installer should include such dependencies.

3) Once I was able to work past the above issues for testing -- I found that I was able to open a client connection (J1939, packetizing ON) but I was not able to send or receive any data to the datalink. We initially set up a thread for reading msgs  -- the call to RP1210_ReadMessage with blocking turned ON seems to lock up our entire process.

I think I need fixes to #1 and #2  -- for #3 is there a debug logging I can turn on to provide you more information? For the record, this code is working without modification for many other adapters.

[DiscoBall]

Hi somaamos,

I am looking into the issue here and should have a reply back to you tomorrow. Sorry for the delay, I wasn't subscribed to this thread.

Joshua B.

PSE - Embedded Networks

[DiscoBall]

Oh. To answer question 3, you can use NI IO Trace (NI SPY). This can be found in the National Instruments folder of the Start Menu. Before starting a trace you will want to go to the Tools menu and click on Options. Then, click on the View Selection tab and ensure that NI-CAN and NI-XNET are enabled.

You can then start a trace, run your application, and then stop the trace after getting the issue. Save the log and sent if to canpse AT ni DOT com.