Automotive and Embedded Networks
UDS services request not responding on NI 8502
You say it is FD at 2MB, but there is more to FD baud rate configuration than just that. I'd suggest opening the XNet bus monitor, and seeing if you can read all the data your ECU sends out periodically first. This way you will know your configuration is right. In my experience buses that are FD data often have a mix of FD and non-FD data in it. This is handled by having two baud rates. The FD baud rate, and then on-FD baud rate. Usually when you configure the bus you will need to say it is at 2MB, but for the non-FD stuff it needs to be something else. I've typically seen 500k for the non-FD stuff. I've only ever seen UDS used on an FD bus once, and the frames responsible for the UDS were non-FD frames. So again I'd look at the bus monitor and see if you can see FD and non-FD frames which will mean your baud settings are right. You may need to mess with the sample point, and termination as well. Remember 2 120ohm resistors should be used, one on each end of the bus. More on wiring here in a blog post.
As for the response in UDS. You are right that once you send a request, the ECU will respond on another ID. But when you use NI's ADCS toolkit, you have to tell the toolkit what ID to expect the response on. If you don't there won't be a response, and the toolkit will generate an error. If you ran a trace from another device, like bus monitor to see the traffic, you might see the request go out, and hopefully see an ID responsible for the response. But NI's toolkit needs to be told where to expect the response. This is sometimes captured in a .CDD file, or .DBC. You can learn more about the ISO15765 protocol (which UDS is built on) here in a blog post I made.
Yeah that looks right. I can't see all of the window with the transmit data, but the ID matches what you said the request (or transmit) ID needs to be. If you aren't seeing any ID as a response from the ECU when sending that, then there isn't any hope the toolkit can function. I'm not sure what else to suggest, because communication is working, but the response isn't there. It is possible the ECU isn't working right, or isn't programmed to use the UDS, or it is possible the request ID isn't correct. If you can get any setup working with this hardware (like vector hardware) then you can bus monitor that and see it working correctly.
@xaheer wrote:
well i have checked ecu working on Vector hardware properly for UDS and also for Peak system. This NI-Xnet hardware USB 8502 is not valid for UDS communication you mean?
That's not what I'm saying at all. I've used that hardware for UDS. What I was suggesting is if the communication is working with Vector, then if you put the XNet hardware on the bus and have it listen, you should see the UDS communication, and that may help you troubleshoot why you are having difficulties.
