PassThru and multiple channels

[Nobser]

I made a very very simple test and logged the difference with the Peak PassThru logger. You will see the startup procedure of the application at first. Then I send a diagnostic message "22 F1 90".

While the startup looks totally similar (one difference: Two connects for dual interface, while just one for mixed mode), please have a look at lines 45/46:
While the dual interface version (which works fine in production environment) retrieves ONE Message on the PassThruReadMsgs command, the mixed mode interface receives TWO of them. I have no explanation for that, maybe someone of you has?

Best regards, Norbert

[Nobser]

Another log with device connected. My idea is, that the "PassThruStartMsgFilter" does not work properly / works different in mixed mode compared to dual interface mode. As you can see, there is no reaction captured from the devices in mixed mode, while in dual mode the answer is captured properly (serial# of device in multiframe response).

Anything I can do?

[F.Vergnaud]

Hello,

I'll answer step by step.

While the dual interface version (which works fine in production environment) retrieves ONE Message on the PassThruReadMsgs command, the mixed mode interface receives TWO of them. I have no explanation for that, maybe someone of you has?

Please check the RxStatus: the first message received indicates 0x09, this is TX_DONE indicating the ISO15765 message was successfully transmitted (it is available in both logs).

" --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x09, TxFlags=0x00, Timestamp=3720213119, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 07 bf ]}"

The RxStatus of the second message is 0x01, the loopback message:

" --> * pMsg[1]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x01, TxFlags=0x00, Timestamp=3720213119, DataSize=0x07, ExtraDataIndex=0x07, Data=[00 00 07 bf 22 f1 90 ]}"

Option Loopback is not set in the dual version, that's why you don't read it.

[F.Vergnaud]

I disagree with your statement regarding the log in mixed mode: you actually received 2 responses for your request "DID F190":

Searching "ProtocolID=0x06" :
in 20241123150522_01_dual_2x.csv (11 results)
Ligne 37: ;;; --> * pMaskMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[ff ff ff ff ]}
Ligne 38: ;;; --> * pPatternMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 05 3f ]}
Ligne 39: ;;; --> * pFlowControlMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 07 bf ]}
Ligne 42: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=486509773, DataSize=0x07, ExtraDataIndex=0x00, Data=[00 00 07 bf 22 f1 90 ]}
Ligne 73: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x09, TxFlags=0x00, Timestamp=486513875, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 07 bf ]}
Ligne 185: ;;; --> * pMaskMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[ff ff ff ff ]}
Ligne 186: ;;; --> * pPatternMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 05 3f ]}
Ligne 187: ;;; --> * pFlowControlMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 07 bf ]}
Ligne 190: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=488259949, DataSize=0x07, ExtraDataIndex=0x00, Data=[00 00 07 bf 22 f1 90 ]}
Ligne 199: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x09, TxFlags=0x00, Timestamp=488261019, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 07 bf ]}
Ligne 200: ;;; --> * pMsg[1]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x00, Timestamp=488298964, DataSize=0x18, ExtraDataIndex=0x18, Data=[00 00 05 3f 62 f1 90 31 43 36 52 52 37 4e 54 30 44 53 37 30 35 37 37 37 ]}

in 20241123150657_00_mixed_2x.csv (14 results)
Ligne 38: ;;; --> * pMaskMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[ff ff ff ff ]}
Ligne 39: ;;; --> * pPatternMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 05 3f ]}
Ligne 40: ;;; --> * pFlowControlMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 07 bf ]}
Ligne 43: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=581816213, DataSize=0x07, ExtraDataIndex=0x00, Data=[00 00 07 bf 22 f1 90 ]}
Ligne 45: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x09, TxFlags=0x00, Timestamp=581817000, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 07 bf ]}
Ligne 46: ;;; --> * pMsg[1]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x00, Timestamp=581857025, DataSize=0x18, ExtraDataIndex=0x18, Data=[00 00 05 3f 62 f1 90 31 43 36 52 52 37 4e 54 30 44 53 37 30 35 37 37 37 ]}
Ligne 47: ;;; --> * pMsg[2]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x01, TxFlags=0x00, Timestamp=581817000, DataSize=0x07, ExtraDataIndex=0x07, Data=[00 00 07 bf 22 f1 90 ]}
Ligne 60: ;;; --> * pMaskMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[ff ff ff ff ]}
Ligne 61: ;;; --> * pPatternMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 05 3f ]}
Ligne 62: ;;; --> * pFlowControlMsg=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=0, DataSize=0x04, ExtraDataIndex=0x00, Data=[00 00 07 bf ]}
Ligne 65: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x40, Timestamp=584461315, DataSize=0x07, ExtraDataIndex=0x00, Data=[00 00 07 bf 22 f1 90 ]}
Ligne 67: ;;; --> * pMsg[0]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x09, TxFlags=0x00, Timestamp=584462209, DataSize=0x04, ExtraDataIndex=0x04, Data=[00 00 07 bf ]}
Ligne 68: ;;; --> * pMsg[1]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x00, TxFlags=0x00, Timestamp=584497002, DataSize=0x18, ExtraDataIndex=0x18, Data=[00 00 05 3f 62 f1 90 31 43 36 52 52 37 4e 54 30 44 53 37 30 35 37 37 37 ]}
Ligne 69: ;;; --> * pMsg[2]=PASSTHRU_MSG {ProtocolID=0x06, RxStatus=0x01, TxFlags=0x00, Timestamp=584462209, DataSize=0x07, ExtraDataIndex=0x07, Data=[00 00 07 bf 22 f1 90 ]}

[Nobser]

Thanks a lot for your analysis and your time.

T'here is one thing, I still don't understand: The main application that is sending all these PassThru-Commands is identical in both cases. So it sends all this stuff for the dual version as well as for the mixed mode version. The application does not know, that I split it's requests to two devices and two channels in one case and to one device in mixed mode in the other case.

Is there any hint, why it works for dual but not for mixed mode? Any idea, what to change, to get an identical behaviour in mixed mode?

[F.Vergnaud]

Maybe the explanation would be that the application is expecting a single PassThru message (the UDS response which is a Protocol ISO15765 message), but in CAN_MIXED mode it also receives the CAN frames that constructs the ISO15765 message. At least one PassThru message is read but does not match the expected protocol... so the application fails/aborts.

[Nobser]

Many thanks Fabrice! That can be the missing link. I'll check that!

Fantastic support!
Best regards, Norbert

[Nobser]

Just a short update (was a long night).

All you said was completely right, Fabrice. It is all there. The diagnostic message is send, the unit answers, the answer is assembled / collected as a complete UDS response and send to the application. We still don't understand, why the application does not detect this response properly.

"Maybe the explanation would be that the application is expecting a single PassThru message (the UDS response which is a Protocol ISO15765 message), but in CAN_MIXED mode it also receives the CAN frames that constructs the ISO15765 message"

It seems to be the other way round! As you can see in the logs, before the UDS request a message filter is set. It is configured as a flow control filter. And that seems to be the major difference:

Using two separate channels with two devices you also can configure two separate, independent filters. So while the diagnostic channel sets a flow control filter the CAN channel still receives the frames that construct the ISO message. When using just one channel in mixed mode, the filter captures all these "standard" can messages and only returns the single UDS message. For what reason ever, this is not enough for the application. It somehow also expects the normal CAN traffic. At least, now that seems to be the case.

I guess this is something I cannot "simulate" with only one channel in mixed mode without losing the UDS auto mechanisms like flow control.

Just out of interest: Is there a reason for not supporting multiple independent channels on ONE device? Background: The application I'm talking about always used PEAK-PCAN devices as preferred CAN devices. So the workflow we have here, with two channels on one device, worked at a time, where Windows XP was still present on the market. When using the old PCAN XP drivers on an old XP PC and the same application, it all works fine with a PCAN USB device using the PassThru interface. What changed?

Nevertheless, many many thanks again for your help and the gorgeous support. Guess, we are on our own for now...

Best regards, Norbert

[F.Vergnaud]

In your log "20241123150657_00_mixed_2x.csv", MIXED format is set to 1:

" --> * pInput={ {CAN_MIXED_FORMAT (0x8000) => 0x1},}"

You should set the value to 2 to receive both the ISO15765 messages and the segmented frames (messages will be treated as ISO 15765, unformatted CAN frame, or both).

Regarding your remark, it feels like the old setup should not have worked at all: internally ISO15765 is built on CAN, having both protocol at the same time on different PassThru channels lead to unexpected behavior regarding the consumption of messages... I'll check wether we prohibited a working feature or an unsupported use-case.

[Nobser]

Hi!

Unfortunately "CAN_MIXED_FORMAT_ALL_FRAMES" does not change the applications behavior in general. There are very rare moments, the application accepts an answer (maybe one out of 50 tries or so), but mostly it fails. So the idea seems to be right, to have a further look here.

"I'll check wether we prohibited a working feature or an unsupported use-case."

When you enter the rabbit hole of "historic source code" Take a look at Ioctl-Parameter 0x10002 (parameter for SET_CONFIG) as well as for IoctlID 0x10100 Also two parameters that worked in the past explicitly for PEAK devices (maybe some secret settings ) and we have to filter now to get it up and running with the most recent driver.

As soon as we find the solution, I'll report!

Regards, Norbert

BTW: The standard frames don't appear in the log, while the message filter is active. Is that correct? So within the log there is no difference between CAN_MIXED_FORMAT_ALL_FRAMES (2) and CAN_MIXED_FORMAT_ON (1)