The data in CAN FD protocol doesn’t sent correctly in SLDRT for PCI Express Peak card

I want to buy CAN FD cards that work well in Simulink Desktop Real-Time (SLDRT). I barrowed a PCAN-PCI Express card from Peak Company.

I tested CAN and CAN FD protocol with 2 ports in SLDRT with MATLAB version R2020b & R2024a in Windows 10.

I connected port1 to port2 with 120-ohm resistance termination in both ends.

When the settings in SLDRT for two ports are CAN protocol, sending & receiving data with packet input & packet output blocks are ok.

But when the settings in SLDRT for two ports are CAN FD protocol, the packet input block doesn’t receive any data.

I checked each packet input & packet output blocks separately with other applications such as PCAN-View from PEAK Company and CAN FD Explorer APP in MATLAB.

With the use of both applications for sending data, packet input block receives CAN FD protocol data correctly.

But when the packet output block sends CAN FD protocol data, both applications in the receiving data section shows CAN protocol instead of CAN FD & length of data is limited to 8 bytes when the length of data is more than 8 bytes.

I think that it may be a bug of SLDRT for CAN FD in packet output block for cards of PEAK Company.

I hope someone help me to resolve this challenging problem for this card.

On the other hand, if someone has successful related with CAN FD cars from Kvaser or Vector company in SLDRT, please tell me the part number of card.

Best regards

Answer 1

[Jan Houska]

Hi Mojtaba,

the CAN FD mode must be enabled in the Board Setup dialog by checking the Use CAN FD checkbox. Have you checked this checkbox? If yes, could you please post your model so I can verify your other settings? Or you may want to contact MathWorks technical support with your question.

Best Regards, Jan

[mojtaba gheibi]

Hi Jan

Thank you so much for your response. I have read most of your answers regarding of SLDRT questions and I hope you help me.

The CAN FD mode enabled in the Board Setup, and the other settings are left as default.

I was able to receive data using CAN FD in SLDRT, so I believe my settings for CAN FD in the Simulink model are correct. However, the sent data seems to be in standard CAN format instead of CAN FD.

I have shared the model and kindly request you to verify it for me.

Best Regards, Mojtaba

[Seokhwan]

I can confirm this issue and have located where the CAN FD information

is lost. Reproduced on R2026b prerelease with a PCAN-PCI Express FD

(Use CAN FD checked, 1000/5000 kHz): SLDRT Packet Input receives FD BRS

correctly, but Packet Output transmits Classic CAN with an extended id

(PCAN-View: 000007AAh / CC), even when feeding an explicitly

constructed CAN_FD_MESSAGE_BUS (ProtocolMode=1, BRS=1, Extended=0),

and even in the shipped example sldrtex_canmessage with only the FD

Packet Output board changed from Virtual CAN to the PEAK device.

The generated code for the Packet Output block (sldrtpo) shows why:

int32_T pktid = msg->Extended ? -msg->ID : (msg->ID | 0x800);

RTBIO_DriverIO(0, STREAMOUTPUT, IOWRITE, msg->Length, &pktid,

(double*)(&msg->Data), NULL);

Only Length, pktid and the Data pointer reach the driver; the

ProtocolMode/BRS/ESI/DLC fields are set correctly earlier in the

generated code but are never passed down. Additionally, pktid encodes a

standard id as (ID | 0x800), yet the wire shows an extended frame,

suggesting the kernel driver interprets bit 0x800 differently.

I have filed this with repro models and generated-code excerpts as

Service Request Case 08908829.

[Jan Houska]

The CAN FD information does not go through the RTBIO_DriverIO call. It is added to the message before the message is sent based on the settings in the Board Setup dialog. So this is by design. Also, adding the 0x800 bit is correct to mark the standard ID.

That said, there indeed seems to be a bug how both the CAN FD flag and standard/extended ID flag are interpreted in the PEAK-System driver that causes the incorrect behavior you describe. This bug appears to be specific to PEAK-System driver only, drivers for all other CAN boards appear to work correctly.

[Seokhwan]

Thank you, Jan. This clarifies the internal behavior of RTBIO_DriverIO and the 0x800 encoding. I had incorrectly assumed that the CAN FD information itself needed to be passed through the RTBIO_DriverIO call.

It is good to know that the actual issue is in the PEAK-System driver’s interpretation of the CAN FD and standard/extended ID flags, and that the other CAN board drivers appear to work correctly.

MathWorks Technical Support has also confirmed this as a product defect under Service Request 08908829 and indicated that a patch can be provided.

Do you know whether this fix is also planned to be incorporated into a future MATLAB release? Also, can I assume that the Kvaser CAN/CAN FD drivers supported by SLDRT do not have this particular issue?

Thank you again for the clarification.

[Jan Houska]

Hi Seokhwan, this particular issue should be PEAK-System only, so Kvaser should not be affected. The fix for PEAK-System is planned to be released with R2026b and also with some next Update for previous releases back to R2024b. Jan