PEAK-System Forum

Hello,

i'm trying to use the PCAN-ISO-TP.dll to communicate to an ECU via PCAN-USB.

As i'm asked to build my program in Python (2.7) on Win7 64Bit. So i created a wrapper for the PCAN-ISO-TP.dll using ctypes and started to integrate a first few simple diagnostic tests for my ECU.

When i'm using the CANTP_Write function to send my data structure, i see the message on the CAN-Bus.
When i'm using the CANTP_Read function, i get a data structure (MSGTYPE: PCANTP_MESSAGE_REQUEST_CONFIRMATION, RESULT: PCANTP_N_OK) even if my ECU is not connected to the PCAN device. The RX DATA field is always filled with my TX-Data. Even if the ECU is attached to the PCAN device, the effect stays the same.

I suspect an problem with the ctypes structure or/and the used DATA c_ubyte Array Buffer but were not able to find an equal problems and helpful solutions in certain forums.

I hope someone here is able to give me a good hint.

CANTP_AddMapping()

Code: Select all

Channel=channel
canID=tx_id,
canIDResponse=rx_id,
canIdType=PCANTP_ID_CAN_11BIT,
formatType=PCANTP_FORMAT_NORMAL,
msgType=PCANTP_MESSAGE_DIAGNOSTIC,
sourceAddr=0, 
targetAddr=0, 
targetType=PCANTP_ADDRESSING_PHYSICAL,
remoteAddr=0

CANTP_Read()

Code: Select all

msgObj = TPCANTPMsg()
tmObj  = TPCANTPTimestamp()
res    = self.__m_dllBasic.CANTP_Read(Channel, byref(msgObj), byref(tmObj))

CANTP_Write()

Code: Select all

res = self.__m_dllBasic.CANTP_Write(Channel, byref(MessageBuffer))

TX Message Structure

Code: Select all

DATA       : <PCAN_ISOTP_Wrapper.c_ubyte_Array_4095 object at 0x02652BC0>
DATA[..]   : 10 03
FORMAT     : 1
FORMAT     : PCANTP_FORMAT_NORMAL
IDTYPE     : 1
IDTYPE     : PCANTP_ID_CAN_11BIT
LEN        : 2
MSGTYPE    : 1
MSGTYPE    : PCANTP_MESSAGE_DIAGNOSTIC
RA         : 0
RESULT     : 0
RESULT     : PCANTP_N_OK
SA         : 0
TA         : 0
TA_TYPE    : 1
TA_TYPE    : PCANTP_ADDRESSING_PHYSICAL

RX Message Structure

Code: Select all

DATA       : <PCAN_ISOTP_Wrapper.c_ubyte_Array_4095 object at 0x02652C60>
DATA[..]   : 10 03
FORMAT     : 1
FORMAT     : PCANTP_FORMAT_NORMAL
IDTYPE     : 1
IDTYPE     : PCANTP_ID_CAN_11BIT
LEN        : 2
MSGTYPE    : 3
MSGTYPE    : PCANTP_MESSAGE_REQUEST_CONFIRMATION
RA         : 0
RESULT     : 0
RESULT     : PCANTP_N_OK
SA         : 0
TA         : 0
TA_TYPE    : 1
TA_TYPE    : PCANTP_ADDRESSING_PHYSICAL

Hello,

I'm seeing somethig extrange within your mapping, Source address and Target address should be different. In your code are both set to '0'. Try using different addresses.

it could be still something wrong with the Python wrapping. Please try using the sample given in C++ to check that the data you send and receive is as expected. This will discard the ISO-TP configuration/communication as error source.

I just modified the C++ example to the same configuration as my python setup. The (CANTP_AddMapping) source address (sourceAddr) and target address (targetAddr) i kept on '0'.

The modified C++ example works as expected with that configuration. I can change the N_SA and N_TA_PHYS addresses without having impact on my transmissions.

It's different in my python setup. if i modifiy the SA or/and TA address to something different than '0', i get an "PCANTP_ERROR_NOT_INITIALIZED" result from "CANTP_Write" and no CAN message is transmitted to the BUS.

Edit:
I have to revert my findings. The modified C++ example shows exactly the same issue as my python script. i think i have to review my entire work again. maybe i made a huge mistake somewhere.Maybe the PCAN dongle is bugging me or the setup itself.

Hello J.Haerig,

Here are some reminders to help you fix your Python/C++ applications:

In an ISO-TP communication, there is a client and a server, for instance: an External Test Equipment defined as 0xF1 in OBD standards and an ECU as 0x01.
When a client sends a request to a server, the source address is the client's address and the target is the server's address. When the server sends a response, it is the other way round : the source is the server address and the target is the client's address.
CANTP_AddMapping let you inform the API that a CAN frame (identified by its CAN ID) corresponds to a specific Network Addressing Information in the ISO-TP protocol and that it should be handle. Therefore to handle physically addressed request/response you need to define 2 mappings, for instance:
- one (with CAN ID 0xYYYY) where source is 0xF1 and target is 0x01,
- and another (with CAN ID 0xZZZ) where source is 0x01 and target is 0xF1.

As a result, setting the same '0' value for source and target addresses is, from a protocol perspective, meaningless. It is all the more true considering that if you use EXTENDED addressing: the target address is copied in the first byte of the CAN DATA.

Hello F.Vergnaud,

i finally found time to dig through my python code again where i found several reasons for trouble.

To help others with similar issues:
- A major point was typification at certain points, which caused no direct influence in my example but had to be fixed to be safe.
- AddMapping had wrong typification, therefore N_SA and N_TA_PHYS was never set properly and ended in an PCANTP_ERROR_NOT_INITIALIZED, when calling the CANTP_Write function.
- Adding 0xF1 as N_SA and 0x01 as N_TA_PHYS was necessary, too.
- I missed to add an recursive call on PCANTP_MESSAGE_REQUEST_CONFIRMATION to trigger an second CANTP_Read call to get the ECU response. That's why i just got my request in the Message object.
- In my case of my ECU i had to set: PCANTP_MSG_PENDING_SHOW, PCANTP_CAN_DATA_PADDING_ON and PCANTP_CAN_DATA_PADDING_VALUE (0xAA), too.

Thanks for you patience and help!

PEAK-System Forum

Python - CANTP_Read returns CANTP_Write DATA

Python - CANTP_Read returns CANTP_Write DATA

Re: Python - CANTP_Read returns CANTP_Write DATA

Re: Python - CANTP_Read returns CANTP_Write DATA

Re: Python - CANTP_Read returns CANTP_Write DATA

Re: Python - CANTP_Read returns CANTP_Write DATA