Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
canTool

Subject: canTool

From: James

Date: 8 Oct, 2010 00:47:03

Message: 1 of 3

I am currently using the Vehicle Network Toolbox with the Vector CANcaseXL Logger to monitor a CANbus with messages being generated from an xPC target simulink model, and have been having some trouble.

canTool, from the Vehicle Network Toolbox, doesn’t decode my CAN messages when I have attached my j1939.dbc file. I believe this is because the function that makes the ID comparison takes into account the source address (SA) of the message. In hex, this is the last two digits of the ID, eg 0x0CF004FE, source address is FE. While important information, the SA doesn’t really have an impact on the message, 0x0CF004XX will still be EEC1 and have the same data format regardless of where it comes from. When I modify my database file to the source address of the messages, canTool works as expected. This is the case for the receive() and extract() functions too. Is it possible to ignore the source address?

Thanks in advance!

James

Subject: canTool

From: Jaremy

Date: 11 Oct, 2010 19:51:03

Message: 2 of 3

Hello,

Currently, VNT does not perform any type of ID sub field parsing nor does it support any specifics of J1939 beyond basic CAN messaging. VNT looks at the ID as a whole. The same message from two separate sources will appear and operate as two distinct IDs in VNT.

This should not hamper receiving messages from the CAN bus. If you are using a database though, as you have already found, you would need to hard code in the SA of your message in the DBC file to have automatic database decoding applied. One thing you can do to work around this is in your database, replicate the message definition from multiple sources as separate messages with the same specification except for the ID value. This will get you decoding applied on receive to all messages regardless of source.

The extraction functions will compare whole ID values as well, but you can work around this too. Instead of specifying a single ID to extract from a log, specify multiple IDs representing each SA you would have. That will get you every instance of the base message, so you can then reference signal data from all messages regardless of source.

Regards,
Jaremy

Subject: canTool

From: James

Date: 12 Oct, 2010 05:59:04

Message: 3 of 3

"Jaremy " <jaremy.pyle@mathworks.com> wrote in message <i8vpr7$423$1@fred.mathworks.com>...
> Hello,
>
> Currently, VNT does not perform any type of ID sub field parsing nor does it support any specifics of J1939 beyond basic CAN messaging. VNT looks at the ID as a whole. The same message from two separate sources will appear and operate as two distinct IDs in VNT.
>
> This should not hamper receiving messages from the CAN bus. If you are using a database though, as you have already found, you would need to hard code in the SA of your message in the DBC file to have automatic database decoding applied. One thing you can do to work around this is in your database, replicate the message definition from multiple sources as separate messages with the same specification except for the ID value. This will get you decoding applied on receive to all messages regardless of source.
>
> The extraction functions will compare whole ID values as well, but you can work around this too. Instead of specifying a single ID to extract from a log, specify multiple IDs representing each SA you would have. That will get you every instance of the base message, so you can then reference signal data from all messages regardless of source.
>
> Regards,
> Jaremy


Thanks Jaremy.
 
Do you know if sub field parsing of the address is a feature expected in future releases of the VNT? I think it would be quite useful.
 
hardcoding the SA's into the database is a good idea but I am logging an unknown bus, so to cover all possible addresses i could potentially end up with a very large number of repeated messages account for each of the possible 255 SA's. A way around this i can see is to log the data on the CANCaseXL and then import it. The issue then becomes the format of the log file...
 
While the CANCaseXL is in the list of supported hardware for VNT, the file formats the logger can convert to do not match the format of the .ASC files supported by canMessageImport(). Below is a sample of the log files that most closely matches the supported import format.
 
>;Timestamp [ns] Timediff[µs] Trigger Type Event Type Data Data Data Data
>757054000 +604µs On/Off CAN (4a8) RX ch:1 Dlc:8 id:8cf00400 data:00 7d 7d 40 1f 00 f0 7d
>757674000 +620µs On/Off CAN (4a8) RX ch:1 Dlc:8 id:8cf00300 data:00 00 30 00 00 fc 00 ff
>758286000 +612µs On/Off CAN (4a8) RX ch:1 Dlc:8 id:98fef700 data:7d 00 00 00 00 00 d0 02
>758898000 +612µs On/Off CAN (4a8) RX ch:1 Dlc:8 id:98fef600 data:00 14 4b 00 00 20 22 00
 
 
Is there support for more logger formats available? Can you offer a suggestion of another work around?
 
Thanks again!
 
James

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us