[CanTp] Vehicle Diagnostic Communication Part 17 [Simulation 5]

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

Introduction.
Installing python-can
Check the operation of python-can
Create replay asc for can.player
Setting BusMaster recording mode
Let’s try to receive what is replayed by can.player in BusMaster.
Conclusion

Introduction.

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

Installing python-can

This time, I will explain python-can, which you have been waiting for.
With this, you will be able to send and receive CAN from python.

Installation itself is easy.
Use pip, a Python package management tool.
So, one command completes the installation.
The world has become really convenient.

By the way, the installation is OK.

> pip install python-can

Some may have encountered errors here.
Depending on the environment in your company, you may need to set up a proxy.
It is necessary to specify a proxy and then execute the following again

> pip --proxy=[proxy server name]:[proxy port number] install python-can

Check the operation of python-can

Let’s check the operation of python-can by itself.
Check it with the following configuration.

Operation check configuration,Python,python-can,can.player,CAN log replay,Virtual CAN Bus,For CAN Monitor,BusMaster

Here, some of you may be wondering about can.player.
This is a module included in python-can.
It can be called as a script to run a stand-alone application.
Think of it as a kind of sample program.

Create replay asc for can.player

First, create the asc file to be replayed by can.player.
The asc file is the CAN log file format used by Vector’s products.
It seems to be the de facto standard as a format, so it is often used by non-Vector companies as well.
As expected, Vector is strong when it comes to CAN.

I wrote the following text in a text editor in accordance with the asc file format.

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

If you are doing CAN-related work, you have probably seen this format before.

The leftmost column is a timestamp and the unit is seconds.
I think can.player is designed to send the data according to this timestamp.
However, I just skimmed through the python-can documentation a few minutes ago, so I don’t even know if it works yet.
Please forgive me if my explanation of this area is a bit vague, but I’m still trying.

Setting BusMaster recording mode

Start BusMaster and make it ready for recording.
Select “Configure” under “Logging”.

Press the add button to specify where the log file should be saved.

Press the add button to specify where to save the log file.

I think the GUI is roughly predictable if you know where to set it up.

Let’s try to receive what is replayed by can.player in BusMaster.

Let’s replay the CAN log with can.player.
The startup command of can.player is as follows.

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

-m: Operating module specification
-i: Interface specification
-c: Channel specification
Replay file specification by parameter without options

The interface is Vector, so -i vector.

And the following is the log recorded by BusMaster.

***<Time><Tx/Rx><Channel><CAN ID><Type><DLC><DataBytes>***
00:00:01:4980 Rx 1 0x111 s 3 01 02 03 
00:00:01:4999 Rx 1 0x222 s 4 0A 0B 0C 0D 
00:00:01:5018 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88 
00:00:01:5069 Rx 1 0x111 s 3 01 02 03 
00:00:01:5089 Rx 1 0x222 s 4 0A 0B 0C 0D 
00:00:01:5110 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88 
00:00:01:5178 Rx 1 0x111 s 3 01 02 03 
00:00:01:5197 Rx 1 0x222 s 4 0A 0B 0C 0D 
00:00:01:5218 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88 
00:00:01:5279 Rx 1 0x111 s 3 01 02 03 
00:00:01:5289 Rx 1 0x222 s 4 0A 0B 0C 0D 
00:00:01:5299 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88 
00:00:01:5368 Rx 1 0x111 s 3 01 02 03 
00:00:01:5388 Rx 1 0x222 s 4 0A 0B 0C 0D 
00:00:01:5408 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88 
***[STOP LOGGING SESSION]***

One might wonder about the asc file format here.
BusMaster itself seems to be an initiative by ETAS, so maybe this format is ETAS’s CAN log format.

If you look closely at the time, you will also notice that it is a bit out of sync with the specified time.
Three frames every 1[ms], which would have specified an asc of 10[ms] cycles….

Perhaps, it seems difficult to reproduce it perfectly.
Perhaps a discrepancy of 1 to 2[ms] in accuracy occurs.

CANoe’s accuracy is on the order of 250 to 500[us], and CANoe’s performance is better.

However, if the two are evenly matched, CANoe’s position will be in jeopardy. Python itself is a scripting language, so it is a little disadvantageous in terms of speed.
But it can be used for approximate testing, right?

Conclusion

I installed python-can.
Checked the operation of python-can.
- Sent by can.player and recorded by BusMaster.
The performance of python-can is on the order of 1-2[ms].
- CANoe has better accuracy.

Click here for back issues.