Comments (17)
Thanks for the clarification. So just to verify that I've understood this correctly:
- There is no "minimal wait time" before an ECU sends the First Frame
- There is no "minimal wait time" before a tester can send the Flow Control frame after receiving the First Frame
In regards to the Timeout, it looks like this is up to 1000 ms based on the above
3) Is it correctly understood that the First Frame will always arrive within 0 to 1000 ms after the Single Frame request?
4) Is it correctly understood that the Flow Control frame must always be sent within 0 to 1000 ms after the First Frame?
I guess what I am unsure about is whether one can rely on the 1000 ms as a standard across all ECUs - or if this is implementation specific. If the latter is the case, do you know if there are some general conventions/good practices to follow in terms of what timings to expect?
Thanks!
from python-udsoncan.
Hi,
I understand the issue you point out. It might be a little tricky to handle. Do you have the reference in the standard that suggest this is the right behaviour?
from python-udsoncan.
Hi pylessard,
After double check, I found that ISO 15765-3 define P2client timeout as timeout for waiting start of incoming response(Single or first frame).
But this standard is revised by ISO 14229-3:2012.
So I need more time to check the standard.
Thanks
from python-udsoncan.
Thank you for your input.
I will wait a feedback from you before looking into any solutions.
Regards
from python-udsoncan.
Hi pylessard,
Could you double check definition of P2 client timeout on 14229-2? I don't have this standard.
from python-udsoncan.
according to ISO-15765-3, the P2_can_client is defined as:
Timeout for the client to wait after the successful transmission of a request message (indicated via N_USData.con) for the start of incoming response messages (N_USDataFirstFrame.ind of a multi-frame message or N_USData.ind of a SingleFrame message).
from python-udsoncan.
ISO14229-2:2013(E) defines P2Client as
Timeout for the client to wait after the successful transmission of a request message (indicated via T_Data.con) for the start of incoming response messages (indicated via T_DataSOM.ind of a multi-frame message or T_Data.ind of a SingleFrame message).
Figure 9 shows the P2Client timer being stopped at SOM.ind
- just after the start of the response message, with the following text:
Client T_DataSOM.ind: transport/network layer issues to diagnostic application the reception of a StartOfMessage. Client stops
the P Client timer.
from python-udsoncan.
Hi all,
Is there a standardized timeout/interval specified when performing CAN ISO-TP requests?
Specifically, I am thinking of the following intervals to be satisfied by the ECU and tester:
tester: Send Single Frame (SF) request
- interval_1
ECU: Send First Frame (FF) response
- interval_2
tester: Send Flow Control (FC) frame
ECU: Send remaining Consecutive Frames (CF)
It is unclear to me if interval_1
and interval_2
above are well-defined - and if so in what standard?
Further, if they are "dynamic" and depend on the specific ECU implementation, how is the tester
(e.g. a diagnostic tool) supposed to know how fast to respond with the Flow Control frame after receiving the First Frame from the ECU?
from python-udsoncan.
Hi @MatinF
Timing requirements would be defined by ISO-15765.
For the specific interval you are requesting, I think there is no requirement. Only timeouts value if the delay is too long.
I am referring to ISO-15765-2:2016 section 9.8
from python-udsoncan.
Hello @MatinF,
- Concerning the
interval_1
:
I think the transport layer handles the request and the response in two different transactions, and is not responsible of theinterval_1
timeout management. This timeout value is managed by the communication layer above the transport layer.
For example, having the UDS protocol in mind, the tester will send, (for example):22 xx yy
as first transport layer transaction62 xx yy 12 34
as second transport layer transaction (which might also be a segmented message)
- Concerning the
interval_2
:
The interval between the confirmation of the request (client/tester side) and the indication of the first frame reception (client/tester side) isN_Bs
from what I see on the screenshot shared by @pylessard, so I would say yes, 1000ms looks correct.
from python-udsoncan.
Thanks for the clarification. So just to verify that I've understood this correctly:
-
There is no "minimal wait time" before an ECU sends the First Frame
I think this is right -
There is no "minimal wait time" before a tester can send the Flow Control frame after receiving the First Frame
I think this is right -
Is it correctly understood that the First Frame will always arrive within 0 to 1000 ms after the Single Frame request?
No. But it is not a timing specification question here, you misunderstood the purpose of single frame and first frame. First frames and single frames does not come one after the other, so First Frame is not expected after a single frame, tehrefore, no timeout value applies here.
Single frame carries an isotp frame in a single CAN message. First Frame is the begining of an isotp frame that requires multiple CAN message. So they are both the beginning of a transmission. They are unrelated.
- Is it correctly understood that the Flow Control frame must always be sent within 0 to 1000 ms after the First Frame?
I think this is right. 1000ms is very long though. From my experience, you can expect it within few milliseconds.
On a additional note.
a 500kbits link will allow a bit more than 4 messages per milliseconds. A good ECU is able to use 100% of bandwidth. In that case, a response is expected within the following millisecond (if the CAN bus is not too much loaded). Many less good ECU will be able to read 1 CAN message per milliseconds, very often limited by software. I even saw one very bad ECU limited to 1 message per 10 milliseconds (ouch.).
If you want to be safe in your implementation, you can leave a 1 or 2 millisecond delay where there is no specification. That will ensure maximum compatibility.
Regards
from python-udsoncan.
Hello @pylessard,
Concerning the hard-coded delay, I'm not sure to understand. The transport layer also specifies the STMin parameter (minimum separation time between two consecutive frames), which is communicated to the client/tester by the ECU trough the Flow Control frame (byte 3). Wouldn't it be the responsibility of the ECU to tell the client/tester to lower the communication speed?
from python-udsoncan.
Yes, between consecutive frames. (I think)
But the interval pointed out by @MatinF are not defined.
I guess the STmin from previous frame could be reused between last frame and next beginning of transmission.
from python-udsoncan.
Just to clarify:
When I mention the time between the Single Frame and First Frame, by Single Frame I refer to the "request" frame to be sent by the testing tool (which will have the same format as a Single Frame in the ISO TP context). Hence, my question was related to what the defined max timeout would be before the ECU must send the First Frame response to the request.
My understanding here is that this delay may be 1000 ms in theory, but in practice it will most likely be far less (e.g. 1-10 ms).
Similarly, the timeout before the Flow Control must be sent by the tester device should be 1000 ms in practice (i.e. N_Bs
), but in practice the Flow Control would typically also be sent far more swiftly after the First Frame response from the ECU (again e.g. within 1-10 ms).
Let me know if I missed something here.
from python-udsoncan.
Hi @pylessard,
I have just faced this issue during testing read dtc request. The expected data flow is as below:
Tester: Send read DTC request
ECU: First frame response
Tester: Send control flow
ECU: Send consecutive frame
ECU: Send consecutive frame
...
Then I got the P2 timeout after 1 second. From my understanding, the lib is waiting for isotp to send receive done notification during waiting for P2 time. However, according to ISO14229-2, the P2 timeout should be the timing between tester request and first response from ECU (which is the first frame). I believe there should be another notification from isotp like start receiving notification to stop the P2 timeout.
Could you share your oppinion?
from python-udsoncan.
Just to let you know that isotp v2.x will be released soon and the possibility of doing a blocking send has been added. This will allow starting the timer at the right moment.
I will see how I can bring that api up to the UDS level so it can be used across connections (that supports it)
from python-udsoncan.
isotp v2.x has been released. and udsoncan 1.21 supports it.
using the new parameter from isotp v2.x blocking_send=True
, this issue should be resolved.
I am still wondering if I should enable something within the udsoncan API for that
from python-udsoncan.
Related Issues (20)
- ReadDataByIdentifier.py TimeoutException Did not receive response in time HOT 2
- send uds req with suppress postive response bit failed HOT 3
- Allow requesting a did without decoding it HOT 11
- Unexpected UDS Authentication message byte order(Subfunction 0x05,0x6) HOT 12
- IsoTPSocketConnection can not be closed with tpsock in blocking mode HOT 5
- struct.error on change_session interpret_response HOT 9
- PythonIsoTpConnection [cilent.py]send_request() tigger TimeoutException,then ISOTP rxthread_task run isotp_send() HOT 7
- IsoTPSocketConnection doesn't work with can-isotp versions 2 and up HOT 9
- Performance tests HOT 16
- When using CAN as a diagnostic channel,other application messages are sent periodically on the bus, calling the client.change_session interface will block at the self.conn.empty_rxqueue() interface. HOT 3
- cannot import name 'Literal' from 'typing' (/usr/lib/python3.7/typing.py) HOT 8
- Act as server and parse python-can messages HOT 6
- No data received: [TimeoutException] Problem HOT 12
- ReadDataByIdentifier: no codec.encode() ? HOT 6
- Security access SAPR response not correctly interpreted HOT 3
- WriteDataByIdentifier service execution returned a negative response IncorrectMessageLengthOrInvalidFormat (0x13) when data length is correct HOT 4
- Adding parameter to Communication Control Service(0x28) HOT 10
- SecurityAccess mishandes a level value of 0 HOT 3
- SocketConnection cannot be closed HOT 5
- P2 timer issue on client.transfer_data(block_number, data HOT 22
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-udsoncan.