Automotive and Embedded Networks
Filter CAN extended Id in XNET Bus Monitor
I have set following extended CAN IDs to filter in Bus Monitor:
On the 'Monitor' tab page I can see the right frames:
The most important thing would be for me to see the frames in the ID-Logger, but the list is empty 😞 Even the logfile is empty, if enabled.
Is there any trick to log filtered IDs?
I use NI-XNET 21.8
@Madottati wrote:
How can a CAN frame be FD and 2.0 at the same time?
With BRS. When CANFD was being created they wanted it to be backwards compatible, so non CANFD devices could still operate on the bus like normal. To accomplish this a CANFD frame can send the ID at the normal CAN 2.0 baud rate, so all devices on the bus can see it and know there is traffic. Then when the CANFD frame goes to send the payload, it can increase the baud rate to the CANFD rate. Now CAN 2.0 devices on the bus won't understand what they are seeing, but it doesn't really matter they just need to know there is traffic, and to wait until the bus is idle before trying again. BRS CANFD messages work this way, but you can also send a CANFD message where the ID and payload are all sent at the CANFD high speed rate. These network configurations will mean only CANFD capable devices should be on the bus.
@TroyK wrote:
I'm not sure this answer is entirely correct @Hooovahh.
My confidence level on the specifics of CAN-FD are low so I'm welcome to being wrong.
A CAN-FD frame with no BRS (Bit Rate Switch and no EDL (Extended Data Length) looks the same as a CAN 2.0 message on the bus. But if the BRS bit is true, then it's CAN-FD. Maybe it's a bug or the flag means something different in CAN-FD context?
When you do CAN-FD without BRS, you still specify a 2.0 Baud and a FD Baud, which is why I assumed it was at the faster rate all the time. If you wanted a bus at just 2.0 baud, I assumed you wouldn't even specify CAN-FD. But I've never seen it on a scope, so you might be right that it is always at the non-FD rate when using CAN-FD without BRS. In any case I've never actually seen CAN FD non-BRS used in the real world. Maybe CAN-FD without BRS just allows for the larger payload but at 2.0 rates?
If you transmit a CAN-FD message on a bus with CAN 2.0 devices then the CAN 2.0 devices will flag EVERY CAN-FD message as an ERROR. CAN-FD can work on the same PHYSICAL bus wiring as CAN 2.0, but it was never meant to be backward compatible with CAN 2.0 devices. The only way it could work is if all the non-CAN-FD devices on the bus could detect a CAN-FD frame in the control field after arbitration and ignore the rest of the message, not setting an error flag. This capability is not in CAN 2.0. It would have to be added to the protocol, making it something other than 2.0.
Oh yes totally agree here about the error frames. If a CAN 2.0 device sees this weird CAN-FD traffic that it can't figure out, it will be detected as error frames. But I don't think it matters. When the bus is idle, it will still be able to send out the 2.0 frames, and then all devices on the bus will be able to read and understand it. This is what I mean by being backwards compatible. I've seen CAN-FD, and CAN 2.0 only devices wired on the bus at the same time. The CAN 2.0 devices will only be able to understand the 2.0 frames, and the CAN-FD frames will be seen as error frames which are clearly not intended for that device to read. But this all functions just fine if you ignore the error frames from data not intended for the device.
Arbitration is ALWAYS at a maximum of 1MBit/s. This a physical limitation determined by the way CAN arbitration works relating to the maximum bus length and the speed of light (or the speed of an electrical signal through copper conductors). BRS only ever affects the parts of the message after arbitration.
This again goes back to my assumption that CAN-FD non-BRS is always at the faster FD rate. It sounds like I'm wrong here and made that assumption since CAN-FD non-BRS needs to specify a FD rate. I can't understand why you would need to specify a FD rate in non-BRS if it is never used.
I can't find a way to set the extended ID flag, I just thought there may be a way, a kind of syntax to tell the bus monitor, that the ID's are extended. Either is this syntax hidden, or it's not possible...
This is everything you can set on the bus monitor.
