Questions on UDS Read ECU Identification.vi

[AldhairGarza]

Hi, im new to UDS and I have a couple of questions about it.

Im trying to communicate to an ECU with the LabVIEW examples.

But I can't get a response. I get the error 8260 and I think i'm missing some configuration.

 I already communicate with the ECU with the XCP or CCP Master Custom Device but with the Diagnositcs I can't get communication.

My question is, how can I know this parameters? Where can I get them from?

Regards

[AldhairGarza]

One workmate gave me the IDs but LabVIEW says they are too long and thus invalid.

Error -1074384605 occurred at Diag CAN open Ex.vi

Possible reason(s):

NI-XNET: (Hex Ox8FF63123) You attempted to set a CAN arbitration ID with an invalid value. For example, a CAN standard arbitration ID supports only 11 bits. If you attempt to set a standard arbitration ID that uses more than 11 bits, this error is returned. Solution: Use a valid arbitration ID.

The IDs are:

18DA27F0x

18DAF027x

Has anyone any Idea?

Thanks.

[Hooovahh]

---

@AldhairGarza wrote:

My question is, how can I know this parameters? Where can I get them from? 

---

The ECU manufacturer, or more specifically the group that wrote the software for it.  Beyond that if you have a .CDD file the information will be in it.  If you have a DBC there is a chance that the TX and RX IDs are in it but they aren't required to be defined there.  The IDs won't be ones that the ECU broadcasts automatically so you can eliminate the possibility of it being any that you see with a bus monitor but guessing the IDs will be practically impossible.  I've never seen the extension IDs be anything other than 0 so there is a good chance you can leave those.

[Hooovahh]

---

@AldhairGarza wrote:

One workmate gave me the IDs but LabVIEW says they are too long and thus invalid. 

---

The issue is that you are trying to use an extended ID but not specifying that it should be extended.  I don't have the ADCS toolkit so I don't know how you set the ID to be extended.  In my CAN Blog Part 8 I go over the ISO-15765 protocol and my examples have the ability to use Extended IDs.  I suspect that NI's toolkit has support for extended...quick Google search found this.

[AldhairGarza]

Hi. Thank you for your answers. Its a honor to get an answer from you.

---

@Hooovahh In my CAN Blog Part 8 I go over the ISO-15765 protocol and my examples have the ability to use Extended IDs.  

---

Yes I found your blog a time ago. I also downloaded your VIs but I'm using a PXIe so they won't work, right?

 I suspect that NI's toolkit has support for extended...quick Google search found this.

Thanks. I searched and found that VI but it's quite strange. The "maximum" input is "FF".

 I cleaned the example from NI just to get the "TesterPresent" Response, but I think the most important thing are those IDs.

What do you think?

[Hooovahh]

---

@AldhairGarza wrote:

Hi. Thank you for your answers. Its a honor to get an answer from you.

---

@Hooovahh In my CAN Blog Part 8 I go over the ISO-15765 protocol and my examples have the ability to use Extended IDs.  

---

Yes I found your blog a time ago. I also downloaded your VIs but I'm using a PXIe so they won't work, right?

---

The core of the ISO-15765 code I provide is in pure G, and will work on any platform NI supports, that supports the basic data types like arrays and clusters.  The real limitation of my code is that I didn't bother writing an example that works with NI-CAN or NI-XNet hardware.  Some day I should probably update it to do that.  Because my example works with Vector, Intrepid, and Kvaser hardware types there are the DLL dependencies to those hardware platforms which doesn't work on PXI.  This probably isn't the right time to dive into it, but my point is that the state machine at the core can be updated to do something like only support XNet, or NI-CAN by replacing the VIs that do the frame reading and writing with NI functions.  But it would probably be easier to just work with NI and their ADCS toolkit since I don't really have the bandwidth to work on that right now, and I get the feeling you aren't up for the challenge.

Sorry I can't help you further but as I mentioned I don't have that NI toolkit installed and I'm not sure how or why NI's functions work the way they do.  Someone more familiar with that toolkit will need to chime in on how to work with extended IDs.

[AldhairGarza]

But it would probably be easier to just work with NI and their ADCS toolkit since I don't really have the bandwidth to work on that right now, and I get the feeling you aren't up for the challenge.

Truth hurts. Yes I'm way far to be prepared for that.

  Someone more familiar with that toolkit will need to chime in on how to work with extended IDs.

---

Yes! I actually found a way to say to LabVIEW that my ID is extended.

"

that's because our driver uses the 30th bit to mark internally, that an extended frame has arrived. You can remove the 30th bit if you make a logical exclusive or (XOR) with 0x20000000. The same applies if you would like to write an extended frame. In this case you have to make a logical OR with 0x20000000 to set the 30th bit thus the driver knows you like to send an extended frame.

DirkW

"

from the post extended ID, NI-CAN-Card

Thank you for your blog and for the hint! 

[Hooovahh]

I wasn't trying to be harsh, if you think you are up to the challenge then please have at it and share your results.  I was just thinking back at how I designed it and it isn't in a very flexible place.  I basically wanted to just get it out and in a place that people could understand the protocol.  Updating it to handle NI's hardware on an RT platform, and ensuring all library and DLL dependencies aren't there is going to be a pain.  Glad you seem to have found what you needed.

[AldhairGarza]

I know you weren't tying to be harsh. I got to the State Machine but it was just too complicated for my knowledge.

Yeah I understand you, but you already made a lot with your blog and your examples. I'm amazed with what you did there.

Best Regards.