[CanTp] Vehicle Diagnostic Communication Part 18 [Simulation 6]

[CanTp] Vehicle Diagnostic Communication Part 18 [Simulation 6] 車両診断通信
[CanTp] Vehicle Diagnostic Communication Part 18 [Simulation 6]

Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/

Introduction.

Let’s simulate ISO-TP. series.
This time, we will play CAN log by can.player of pyton-can & record by can.logger.

Configuration of this experiment

Last time, logs were replayed by can.player and recorded by BusMaster.
In contrast, this time, the following configuration will be used for recording.

Experimental Structure,Python,CAN log replay,can.player,CAN recording,can.logger,Virtual CAN Bus

Here comes a new one called can.logger.
This will be another kind of module for python-can.

As you can guess from the name, it is a module that records like BusMaster.
Previously, we have confirmation of python-can sending by can.player, but not of receiving.
If can.logger can record the data, it can be judged that python-can is being received successfully.

Replay with can.player

The flow of what to do is as follows:

  1. launch two Anaconda Prompts (the first one is Prompt1 and the second one is Prompt2)
  2. start can.logger with Prompt1
  3. Start can.player with Prompt2

Now can.logger will record the CAN frames replayed by can.player.
CAN frames are sent out immediately after can.player is started, so can.logger must be started first.

The asc file created in the previous session is replayed as is.

Begin Triggerblock 
 0.000000 Start of measurement
 0.000000 1  111       Rx   d 3 01 02 03
 0.001000 1  222       Rx   d 4 0A 0B 0C 0D
 0.002000 1  333       Rx   d 8 11 22 33 44 55 66 77 88
 0.010000 1  111       Rx   d 3 01 02 03
 0.011000 1  222       Rx   d 4 0A 0B 0C 0D
 0.012000 1  333       Rx   d 8 11 22 33 44 55 66 77 88
 0.020000 1  111       Rx   d 3 01 02 03
 0.021000 1  222       Rx   d 4 0A 0B 0C 0D
 0.022000 1  333       Rx   d 8 11 22 33 44 55 66 77 88
 0.030000 1  111       Rx   d 3 01 02 03
 0.031000 1  222       Rx   d 4 0A 0B 0C 0D
 0.032000 1  333       Rx   d 8 11 22 33 44 55 66 77 88
 0.040000 1  111       Rx   d 3 01 02 03
 0.041000 1  222       Rx   d 4 0A 0B 0C 0D
 0.042000 1  333       Rx   d 8 11 22 33 44 55 66 77 88
End TriggerBlock

The following commands are used to start can.player and can.logger.

> python -m can.player -i vector -c 0 canlog.asc
> python -m can.logger -i vector -c 0 -f canlog2.asc

-m: Operating module specification
-i: Interface specification
-c: Channel specification
-f: Specification of recorded file

Now, let’s check the asc recorded by can.logger.

can.logger to receive

Begin Triggerblock 
 0.000000 Start of measurement
 0.000000 1  111             Rx   d 3 01 02 03
 0.002097 1  222             Rx   d 4 0A 0B 0C 0D
 0.003940 1  333             Rx   d 8 11 22 33 44 55 66 77 88
 0.009920 1  111             Rx   d 3 01 02 03
 0.011952 1  222             Rx   d 4 0A 0B 0C 0D
 0.013984 1  333             Rx   d 8 11 22 33 44 55 66 77 88
 0.018071 1  111             Rx   d 3 01 02 03
 0.020078 1  222             Rx   d 4 0A 0B 0C 0D
 0.021930 1  333             Rx   d 8 11 22 33 44 55 66 77 88
 0.029016 1  111             Rx   d 3 01 02 03
 0.031089 1  222             Rx   d 4 0A 0B 0C 0D
 0.033030 1  333             Rx   d 8 11 22 33 44 55 66 77 88
 0.038912 1  111             Rx   d 3 01 02 03
 0.041058 1  222             Rx   d 4 0A 0B 0C 0D
 0.041927 1  333             Rx   d 8 11 22 33 44 55 66 77 88
End TriggerBlock

It’s all there.
The accuracy is the same as when I checked with BusMaster, and it deviates by 1 or 2 [ms].

This time, the output was in asc format, but can.logger can output the following formats.

  • asc
  • blf
  • csv

The format is determined by the file extension when the name of the recorded file is specified at the startup of can.logger.

While asc and csv are text format files, only blf is a binary format file.
This is also one of Vector’s CAN log formats.
Since it is a binary file, you will not be able to see what it says even if you open it with a text editor.

If that is the case, I think asc would be a better choice…
The advantage of blf is that the file size is smaller and the recording load is reduced.
However, CANoe or CANalyzer is required to view the contents.

However, if you have CANoe or CANalyzer, there is no need to use Python….

Possible situations are the following.

  • Can.looger is incorporated into a Python-based automatic measurement system and recorded.
  • The recorded data is later compiled and checked by CANoe.

This is a very limited situation.

It may not be useful, but just remember that blf can also be handled.

Conclusion

  • CAN transmissions were replayed in can.player and recorded in can.logger.
  • There are three file formats recorded by can.logger.
    • asc, blf, and csv.

Click here for back issues.

コメント

タイトルとURLをコピーしました