Automotive and Embedded Networks
Automotive Diagnostic Command Set USB Transfer Data Error
Sorry you are having issues with OpenG. I have back saved the majority of my CAN stuff back to 2012 which is done outside of a package. As a result it is a manual process to install it. You don't just double click a package and have VIPM take over.
So first install all the normal OpenG packages through VIPM. If you can't you can probably just copy over the user.lib from another computer. Then install XNet if you intend on using the frame and signal conversion or XNet tools. Then download my code here. Then extract that zip to your LabVIEW install folder which will likely either be one of the following for you:
C:\Program Files (x86)\National Instruments\LabVIEW 201x
C:\Program Files\National Instruments\LabVIEW 201x
Then restart LabVIEW. Now you should have a Hooovahh palette on your block diagram.
The Integer to Enum can probably be replaced with a coerce to type. I've been using this 15765 code on various projects successfully lately, and I think the main core state machine, and the diagram on my blog should document it well enough for you to adopt it to your own. I'm working on XCP right now, but is being developed on company time so this one might be harder to post.
Okay well thank you for that, apparently I missed the ISO 15765 protocol in the back save that I posted. If you can try to again download the back saved code for 2012 from here. It now contains the back saved code of which I can't really test since 2015 is the oldest I have at the moment. I also added the MNU files to for the ISO palettes too.
hi Hooovahh
I tried to do a small demo to see if it all works but I'm probably doing something wrong. This is how I set it up, trying to send a multi-frame message:
The disabled CAN demo in your set of VIs works fine and I can detect the data using a P-CAN. But when I run the above circuit I made, it gives a timeout error and when I debug further I saw this in 'CANTransmitSingleframe.vi':
Error 6101 occurred at ISO 15765 Class_ISO.lvclass:Write Single Frame_ISO.vi
Possible reason(s): vector xl driver error 101XL_ERR_WRONG_PARAMETER
I see the xLCANTransmit for the working CAN demo in for 'CANtransmit.vi' ....
...is configured differently compared to 'CANTransmitSingleframe.vi' used in the 15765 vis:
That's all I could find for now. I'm sure the problem is in how I set up the 15765 demo since your CAN demo works and you said you've been using your vis successfully.
You are doing multiple things wrong, and without access to the hardware I can't be sure what all the issues are. The first issue I see is you are stating that the the request ID is 0xAAAA1111, and the response is 0xAAAA2222. Every example I've seen of diagnostic CAN is on standard CAN IDs which are only 11 bits. Your example is 32 bits. Even if it was an extended CAN ID that is only 29. If your device actually need extended CAN IDs you'll need to modify the code to send and receive extended IDs (it is just a boolean in reading/writing frames) but more importantly I suspect your IDs are wrong. Trying to write this ID which is greater than 11 bits on a standard frame is probably why you are getting the Wrong Parameter error.
Then there is the question of your payload. You send a request of 0x2EFE0100FF000101. Do you intend on this performing a UDS Write DID? If so then you can just use the UDS Write Data By Identifier, which has the ID and Data In as separate controls, and also performs error handling and negative responses. It appears you are trying to write the DID 0xFE01, with a payload of 0x00FF000101 is this correct? If so you may want to start small and see if you can read this DID using the UDS Read Data By Identifier. Odds are that DID is protected and can't be written to until you enter the Extended or Programming mode depending on where that memory is mapped to. This is done with the UDS Diagnostic Session Control. Depending on your ECU you may need to perform a Seed/Key after entering that mode, to have access to writing that DID.
The difference in the transmit VI is because we know when performing diagnostic functions we only need to write a single frame at a time. This means that the Transmit can be simplified into the Transmit Single Frame where the input is a cluster instead of the array of clusters, we can remove the for loop, and have a constant of 1 as the number of frames to transmit.
And lastly in the future post code, not pictures of code. These were simple enough to understand but a snippet or the VI is much better than an image since a jpeg is not executable code. It is like taking a screenshot of notepad.
I don't know what the hardware baud rate will initialize to but it might be incorrect. Here is how you get access to the Vector Hardware and set it.
Also notice that I broke out the Hardware Channel this should also have valid data in it. The fact that you are getting an error from the Vector driver makes me think this part is working but it might tell you if you are on the wrong port or channel. Remember this example uses the first non-virtual port it finds, and if it doesn't find any it will still try to initialize and will error out. Make sure no other software is using that port when you run the VI. This means CANalyzer, CANoe, CANape, and any other VI are not actively using that port (VIs not running and Vector software stopped). That might be one reason you get a offline error.
