Closed anthonyhbest closed 1 month ago
We will need to audit the communication layer to understand any changes needed to support shared addresses. It was not an expected condition.
Destination specific TP is not possible for two devices sharing a single address. One possibility would be to only display this error when TP control messages are observed.
Should we log the other device's traffic in the report? Do we know that it isn't clearing faults or starting tests? Do we care?
Can we get a CAN log? I'm interested in what the address claim negotiation looks like in this case. I don't need the whole log.
Options to be discussed 1/20/2023:
Development will report back with description of tool address claim procedure.
From 1/202023 User Development Discussion:
Item 1 — Always show the perceived excess query in the logs (report and .ASC) Item 2 — Display the popup once, upon the first occurrence of excess SA F9. Allow user to Abort or continue. The existing abort button in the UI may provide this function. Item 3 — Complete the current response window data collection, where practical. The tool may continue with next test step once the current response window closes. Item 4 — Accepted as heuristic improvement. Use a global DM5 query for the heartbeat concept not less than every 10 seconds and not more than 30 seconds.
Tool now has numerous pop-ups now due to a remote diagnostics device operating on SA F9:
These pop-ups appear to be stalling the tool, which results in mass failures for whole sections of the test where the tool does not collect the data provided by the truck. In just parts 1 and 2 alone I had exceeded 130 failures. I know we have discussed the root cause of this issue in the past, and there should be some penalty for the remote diagnostics device communicating using SA F9. However, this behavior and subsequent penalty, at least upon initial review, seem excessive for the situation.