CAN FD+BRS - LabVIEW programming

[RASedden]

I need to interface to an ECU which communicates using CAN FD+BRS. I am using an NI USB-8502 interface. When I use the NI XNET Bus Monitor I can see the frames being received. So I know the data is there and that is can be read successfully into the PC

I have a simple CAN Receive app that initialises a session in XNET and reads CAN data - a labview analogue for the Bus Monitor. I now need it to work with CAN FD and read the data I can see when I use Port Monitor. I have added the extra parameters to specify the IO Mode (CAN FD+BRS), the FD Iso Mode (I've tried all options) and I have put the data baud rate (2,000,000) in the BaudRate64 field. Whilst my simple app works with normal CAN, I cannot get it to work with CAN FD.

Ideas anyone ?

[JefeL]

The correct ISO mode is very important as they aren't interoperable. ISO is the most common now days. Since you are able to see frames with the Bus Monitor I would copy that setting.

Assuming your termination is also set correctly your program looks like it should work to me. We can try using the ":can_fd_brs:" in-memory database as the cluster.

[iwane]

Hi all,

 Just my $0.02 from experience: CAN FD is VERY sensitive to timings. If you have any mismatches in sampling point/time quantas, it can refuse to work properly. You can have several different settings for 2MBit/s - pay attention to all nodes. They should use the same settings.

[RASedden]

I dug into some of the NI manuals and took a note of what you both said. It works 🙂

Thank you both for your input

Andrew

[JefeL]

To be clear the picture you attached is showing the receipt bus error frames and not successful data transmission. We can decode this frame per the special frames documentation. Your receive error counter is maxed out and the error type is a form error.

Form errors would be expected if you are using the wrong ISO mode. They would also be very common if the timing of your sample points are not correct as iwane suggested. Here is a KB that describes the challenges with sample points in CAN FD.

One way to tell which issue you are running into is look at a large number of error frames. If you have the wrong ISO mode, every error frame will be a CRC error. If your sample point is off, you should see a mix and match of form, stuff, and possibly other errors although most will likely be form errors depending on the data being transmitted. The bus monitor is a good tool for this as it allows you to look at 100s of frames and even log them to disk if you want. Make sure the BM settings exactly match those of your application.

If you end up needing to try custom baud rates the easiest way is to use the XNET utilities to calculate them for you. Both the BM and database editor provide a simple UI to adjust your sample point. Simple choose the standard baud rate you need from the drop down menu. Then open the drop down again and select custom. As the KB I linked explains, you will be mostly concerned with the NON-FD baudrate. This is counter intuitive but critical to understand. You can try adjusting your non-FD baud rate sample point up or down by one "click". I would try down first and the bus monitor is a great tool for this type of iterative testing.

Then you can copy the hex value in the "Custom Baudrate" and use it in your application.

[RASedden]

Thank you for your ongoing help

When I run Bus Monitor it displays valid data - the ecu firmware engineer has told me to expect 528 messages (0x210) of varying lengths and this can be seen in Bus Monitor.Main.png. So I then check its settings - see Bus Monitor.Interface Settings.jpg & Bus Monitor.Custom FD Baud Rate.jpg

I then copied these into my vi XNET CAN FD Rx.2 - Terminal.vi and run it. LabVIEW.Front Panel.jpg shows the reults - still a full house of rrors & LabVIEW.Block Diagram.jpg show my code with the custom baud rate and ISO mode attribute.

When I cycle the power to restart the DUT I sometimes see LabVIEW crash with XNET Err.jpg error message

The problem I face is that I believe I have configured my LabVIEW vi to do the same as the Port Monitor. But it would appear that I have missed something ?

Andrew

[JefeL]

No it doesn't look like you have missed anything. Your code looks correct and is virtually identical to the code used by the bus monitor itself. If the BM settings are working I would expect your application to. 

The Intf.BaudRate property was depricated a few versions ago in favor of a new property called Intf.BaudRate64. The old version of the property "should" work fine to prevent breaking backward compatibility. The bus monitor uses the new version of the property so this is the only minor difference I can see between the two applications. On a hunch, can we try switching the Intf.BaudRate property to Intf.BaudRate64? Also change the data type of the input to U64 to eliminate any casting issues as shown...

I did some testing with this hunch but couldn't reproduce any problems. Your code worked fine. However, I may not be using the same versions of software and I am not sure what versions you are using. Can you also provide me with software versions in use?

[RASedden]

I swopped the baud rate parameter over as suggested. No change.

I have also attached my software versions (I hope)

Thank you for your ongoing support - this is most frustratitng !!

Kind regards

Andrew

[JefeL]

This is very strange since it works on BM. Lets take a very close look at the sample points again.

• Change the Intf.CAN.FdBaudRate64 property to 2000000 for all tests below.
• Try using each of the following Intf.BaudRate64 values in order

Sample Point	Intf.BaudRate64(Hex)	Notes
87.5%	32A0042104	Default 500 kBd
85.0%	32A0042005
82.5%	32A0041F06
80.0%	32A0041E07
90.0%	32A0042203

If a particular setting works, make note of it and let me know so I can dig deeper and figure out why your application behaves differently from the BM.

[RASedden]

Out until Monday I'm afraid but I will be onto it first thing. Thanks for your ongoing help

Andrew