XCP and CCP in LabVIEW (and X-NET)

[ninick]

Hello,

My actual requirements are a bit nebulous at the moment but just assessing my options.

Has anyone had any luck with 3rd party software with XCP/CCP and LabVIEW? This could be 3rd party hardware or XNET stuff. Maybe a home-brew driver or vendor supplied?

I realise NI offers the  NI ECU Measurement and Calibration toolkit for XCP/CCP support with XNET hardware but I want to know if this is my only option!

Thanks!

[hooovahh]

I've been in the process of re-writing the XCP/CCP drivers to work with other hardware.  A while ago I re-wrote the ISO-15765 drivers (KWP2000, OBD, UDS) into pure G so that any CAN hardware can use it.  This basically replaces the NI Automotive Diagnostic Toolkit from NI.  The code was simple enough and all I needed to do was re-write the core state machine and the rest was more or less the same NI subVIs.

XCP/CCP is more complicated as there isn't just a single core used by NI's toolkit to replace.  I do have an internal toolkit for doing XCP, but parsing and processing the A2L file still leverages NI's DLLs and if I ever wanted to release it I would want to rewrite this file parsing stuff too.  My toolkit does support a Raw mode which doesn't rely on an A2L (and doesn't need NI's parsing) but in this case doing things like reading a characteristic you'll need to provide the Address, Extension, Byte Order, Number of Elements to Read, and Number of Elements in an Item.  Returned would be an array of bytes.  Where when using the A2L you can call a function to list all the Characteristics by name, and then read the engineering unit based on the name, with all that other stuff pulled from the A2L.  I was able to accomplish this just by sniffing the CAN bus while using NI's toolkit and seeing the commands performed to do things like Connect, Unlock, Get Processor Info, Get DAQ Resolution, get PGM Info, etc.  NI's toolkit has an ECU simulator, and I have a couple actual ECUs to test with.  Combined with sniffing I found some documentation here that helped understand the protocol more.  At the moment I can't post what I have, way too coupled with NI, and not robust, and cleaned up.  But I can point you in the direction of what I learned if you have any questions about the order of commands needed for an operation, or the type of things needed.  If your scope is small enough I'd attempt to just use NI's toolkit on your ECU, sniff the bus, and figure out what the commands are to get what you need.

But honestly for the money the NI toolkit is worth it.  I'd argue the ADCS toolkit might not be worth it (since it is available on my website and open), but the ECU one is and if you can get away with using NI hardware I'd recommend using that toolkit.

[Tim_S]

The only other company I know of that does XCP is Vector. Vector does have a .NET interface for their CANoe/CANAlyzer software, and there is a way to broadcast/receive UDP from their VN boxes. The price tag on Vector hardware and software is pretty hefty (I expect 14k to 25k USD every time I get a quote for a single station).

Dearborn Group with their Gryphon boxes may be able to do XCP/CCP. Haven't done anything with them in a decade, so can't relate much more. Once again not cheap.

Kvaser is an outfit I've heard about and briefly looked into a couple years back, but not used any of their products.

[hooovahh]

Vector isn't the only one, Intrepid has hardware for doing it, and ETAS does too.  But as far as software capabilities go none of these hardware options provide drivers which are capable of doing this in LabVIEW.  They may have LabVIEW drivers for reading and writing raw frames but no software layer on top of that other than NI's, or writing your own.  I've avoided the .NET capability due to the high price tag of having that software and hardware on the system.  Vector hardware is licensed for software so installing CANoe, and then calling it via .NET only works if you buy Vector hardware, then pay for it to have CANoe enabled.

[ninick]

Hi Hooovahh,

Thanks for your reply. (P.S your CAN series on your blog has been super helpful in the past - thanks!)

Getting a bit confused when you refer to 'toolkit' whether you are referring to the ADCS toolkit or the ECU toolkit (and XNET driver I think)

Also, unfortunately the link here is broken: 

23 hours ago, hooovahh said:

Combined with sniffing I found some documentation here that helped understand the protocol more

All that aside, proper A2L support is essential really as these will chop and change and I can't go packet sniffing everytime that happens.

Looking like the ECU toolkit is gonna be required. Pretty sure some people are gonna wanna buy Vector kit though...

Thanks!

[hooovahh]

Sorry if I wasn't clear.  NI's ADCS has more or less been replaced by the ISO 15765 I posted online.  It doesn't do hardware abstraction with classes (it should) but I was just in a hurry to post it online and thought most people would just be interested in the G state machine.  Turns out most people are interested in a different things.  The ECU toolkit is the one I've started to replace but may never be able to post online.  This is the one that uses an A2L for XCP/CCP.  If I had time to work on it I would probably update the ISO 15765 toolkit I posted online first to add hardware abstraction, and then make a post on how to flash an ECU using it.  That is a lot less effort than re-writing the ECU toolkit.

That documentation link isn't broken, it is just realllllly slow.  I downloaded it and attached it here.

XCP -Part 2- Protocol Layer Specification -1.0.pdf

[ninick]

This clears things up and yes I have the file now.

I think your ISO15765 toolkit could prove useful too. 

The NI ECU toolkit is fairly good value tbh, so its not too big a sell. 

Thanks for all your help.

 

Edited November 9, 2018 by ninick

[Chris Sebastian]

@hooovahh I know this is an old thread, but there is not much info out there on this topic from what I can find! We are in a similar situation in that we would like to leverage some existing code (either from the ECU toolkit or now there is a VCOM toolkit) to parse a2l files and edit calibrations, but we would like to use Kvaser hardware instead of NI for the CAN communication. I have been able to download a trial of the VCOM toolkit, but it is password protected and so far it is unclear if the password protection is removed on purchase. I am not able to download the ECU toolkit, and so I am not sure if that is password protected also!

We don't mind purchasing a toolkit and modifying it to work with Kvaser hardware, but I am not sure if that is possible and our distributor support has not been super helpful!

[hooovahh]

I would not count on purchasing a license, causing the passwords to be removed.  Sorry.  Additionally the NI toolkits are often just wrappers around a DLL or some binary. This means for it to work it must hook into NI specific function calls to NI specific hardware.  The ADCS toolkit works this way and that's why I had to rewrite it to allow using different hardware.  The ISO 15765, XCP, CCP, KWP2000, UDS, J1939, and other CAN protocols are really just software layers on top of some frame level API.  They can all be written in a way that is hardware agnostic.  But NI's toolkits are not written this way. NI wrote their ECU toolkit to work with NI hardware, and they want to keep it that way. The hardware helps sell software, and the software helps sell hardware.   They don't have an incentive to have it work with other hardware.  But honestly their hardware is quite good. I really like the NI USB 8502.

[Chris Sebastian]

Thank you for taking the time to reply, it is very much appreciated!

1 hour ago, hooovahh said:

I would not count on purchasing a license, causing the passwords to be removed.  Sorry.  Additionally the NI toolkits are often just wrappers around a DLL or some binary. This means for it to work it must hook into NI specific function calls to NI specific hardware. 

I guess I naively did not consider this, I just assumed they would be written to be hardware agnostic! I suppose it does make sense though, given the business model of selling hardware and software.

1 hour ago, hooovahh said:

But honestly their hardware is quite good. I really like the NI USB 8502.

I think we will have to seriously consider our path forward, I have nothing against NI CAN hardware, we just already use Kvaser, Peak, and Vector tools and I really hate to add another one in the mix!

[hooovahh]

Yeah I get this. We also have Intrepid, and ETAS in the mix along with other random serial to CAN converters. It can be a bit of a hardware mess.  I have written class wrappers around different CAN hardware, and then made a single API for doing things that use most of these hardware types. But I haven't got permission to share it, and specifically the XCP and A2L side of things, leverages NI's toolkits in ways that I can't share it openly in the state it currently is.  Sorry.  If I had more time, resources, and didn't develop it on company time things would be different. The large majority of the stuff on my blog was developed over a week at home during a staycation.