Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

NI XNET : Is it possible to start multiple sessions one set (in and out) for CAN(2.0) and other for CAN FD on the same interface(port)?

Highlighted

NOTE : I am using "NI XNET API for C" and no Labview API or components.

My applications current behavior :
Based off classic CAN(2.0) or CAN FD, we use either the ":memory:" or ":can_fd_brs:" database to start an in session "nxMode_FrameInStream" and out session "nxMode_FrameOutStream" and set respective baud rates.

 

Current request :

The requirement is to send specific frame requests using CAN FD BRS features, but rest off all requests should be using classic CAN.

Is it possible using same interface (CAN1,CAN2...) we can start two set of sessions(in and out) first for CAN(2.0) and second for CAN FD?

 

0 Kudos
Message 1 of 5
(104 Views)
Highlighted

Note: I am a LabVIEW developer but I think the API similarities means I can help.

 

So CAN FD has some support for various legacy CAN stuff.  CAN FD as you've probably noticed has two settings for the baud.  The normal CAN 2.0 speed, and the CAN FD speed.  I've seen stuff like 500k baud for 2.0, and 2M for CAN-FD.  This means that at the start of the CAN Frame there is a Start of Frame Bit, Arbitration ID, and a few bits for data length.  This data will be transmitted at 500k and all normal non-CAN-FD devices on the bus can see and read this.  Then we send the payload which is sent at the higher 2M baud.  Then after that we slow back down to 500k for CRC and a few other things.  To a non-CAN-FD transceiver on the bus this will end up looking like a corrupted frame, because the data in the payload won't be sampled fast enough, and the CRC won't match.  But the reverse will still function.  A non-CAN-FD device may send a frame at 500k, and the CAN-FD device that runs at 500k/2M will see the frame and be able to read it as a normal CAN 2.0 frame.

 

Well what if we were a device setup as CAN-FD using the :can_fd_brs: database, and instead of sending at 500k/2M we sent it at 500k/500k?  Then it will be a valid CAN 2.0 frame, and all CAN 2.0 devices will be able to read it no problem.  So how do we do this with NI hardware?

 

This is controlled with the I/O Mode of the frame.  If you open the XNet Database Editor (should be in your start menu installed with XNet Utilities) you can make a sample database.  Then make a CAN Cluster, setting the I/O Mode to CAN FD + BRS, then set the bauds how you want.  Now make a frame under that cluster.  The I/O Mode will default to CAN FD + BRS, but if you change that to just CAN then it will use the slower CAN 2.0 baud for the whole transmission.  You can save this database and reference it in your application, or you can dynamically generate the database in memory as you have been doing, just set the I/O mode for the frame.  Doing it this way means you can use one database for both CAN-FD and CAN 2.0 frames.  I have a CAN Blog post on CAN-FD, but reading through it I realize I left off a bunch of this information so it might not be that helpful. 

0 Kudos
Message 2 of 5
(60 Views)
Highlighted

Thanks for your reply.

Here's my interpretation of what you are suggesting

- Creating an empty database with I/O CAN FD + BRS, is similar to what I do internally using ":can_fd_brs:" database. 

- So while sending frames I send it as standard CAN frame type "nxFrameType_CAN_Data", and if a CAN FD frame needs to be send out then it's of type "nxFrameType_CANFDBRS_Data".

I see there is one more macro "nxFrameType_CAN20_Data". The documentation doesn't say much about these different types. 


Do you know what it means? Should I be using this instead to send standard CAN frames when setup as CAN FD BRS? 

 

// From nixnet.h file

/***********************************************************************
                                F R A M E
***********************************************************************/

   // Type
#define nxFrameType_CAN_Data                 0x00
#define nxFrameType_CAN_Remote               0x01
#define nxFrameType_CAN_BusError             0x02
#define nxFrameType_CAN20_Data               0x08
#define nxFrameType_CANFD_Data               0x10
#define nxFrameType_CANFDBRS_Data            0x18
#define nxFrameType_FlexRay_Data             0x20
#define nxFrameType_FlexRay_Null             0x21
#define nxFrameType_FlexRay_Symbol           0x22
#define nxFrameType_LIN_Data                 0x40
#define nxFrameType_LIN_BusError             0x41
#define nxFrameType_LIN_NoResponse           0x42
#define nxFrameType_J1939_Data               0xC0
#define nxFrameType_Special_Delay            0xE0
#define nxFrameType_Special_LogTrigger       0xE1
#define nxFrameType_Special_StartTrigger     0xE2

 



0 Kudos
Message 3 of 5
(49 Views)
Highlighted

@mahajan24 wrote:

 

I see there is one more macro "nxFrameType_CAN20_Data". The documentation doesn't say much about these different types. 


Do you know what it means? Should I be using this instead to send standard CAN frames when setup as CAN FD BRS? 


That's a good question, I would suggest using the CAN20_Data when trying to send a non-CAN-FD frame but I admit I don't know what the difference is, probably some legacy support before there was a CAN-FD standard.

0 Kudos
Message 4 of 5
(44 Views)
Highlighted

So setting the frame type to "nxFrameType_CAN20_Data" seems to be working when in CAN FD setup.

 

Thanks Hooovahh for talking it out with me.

ATTN : NI support

Can some one tell me what these different frame types mean and when they should be used? So I can have options in my application to handle situations like this?

#define nxFrameType_CAN_Data                 0x00
#define nxFrameType_CAN20_Data               0x08
#define nxFrameType_CANFD_Data               0x10
#define nxFrameType_CANFDBRS_Data            0x18
0 Kudos
Message 5 of 5
(36 Views)