Automotive Diagnostic Command Set USB Transfer Data Error

[Hooovahh]

Okay attached is the updated ISO 15765 Transmit Block.vi which has the updated logic for when Block Size is 0, and back saved.

[ssdet]

Ah thank you very much, its working now. The CAN frames are being sent and received properly when I spy on the lines. I think its also receiving multi-frame correctly.

However its not returning a reply in the DataOut field. I'm debugging and checking to confirm that the next state after a Write Single or Write Chunk is 'Read Reply' if we are requiring a reply and then checking if we get a value in the DataOut when that VI is done running.

[Hooovahh]

Sweet, sorry such a simple thing took so long, but you should feel good knowing others will benefit from your debugging, including myself.  No data is a weird one.  Yes obviously it should to go Read Reply after Write Chunk of Data, at which point it should read a single frame, and go to Process Read where we should go either to Read First Frame, or Read Single.

[ssdet]

Thanks yes it will be useful for everyone after this debugging is done. Thanks so much for all your help with this and also thanks for writing this 15765 program. I dont think I could have written it by myself in the time I have available and I would just be able to implement some limited functionality specific to Vector and you've done it for other devices too and there's so many other VIs that you've created. Its pretty complex. You did a great job. In an ideal world these hardware companies would compensate you for this effort.

So I debugged why there wasnt a value and I found in the Quit case, the default value is being written out for 'Data Out'. So I just wired the wire through the Quit case from the input to the output, easy fix thankfully and now I'm getting the value out of the VI. File:   \CAN ISO 15765\Core\Read and Write Diagnostic State Machine_ISO.vi

This is now successfully giving the final data value assembled from the multi-frames which I can now parse in my program.

Do you know how I can set up periodic CAN messages? I tried looking at the other Vector CAN VIs you have and also at the 15765 Class to see if there was a periodic property I can set to True and set the rate in millisec, but I couldnt find it. I searched "periodic" in VxLapi.h to see if there's any function names or comments with this keyword but I couldn't find it.

One thing, I found some VI's had their execution option set to 'preallocated clone' which will result in new memory being allocated every time the VI runs. I will change it to 'shared clone'. This will result in lesser memory usage. I found this out when I had pre-allocated clones and my program Exe would go up to 1.5GB of ram usage after it ran for a while in the production facility. So I found if I use Shared clone, it reuses a clone when it can. Now the memory usage stays stable at 150-170MB.

From your VI's I've learned about the Inline and disable-debugging options which I assume are used for faster execution.

[Hooovahh]

---

@ssdet

 So I debugged why there wasnt a value and I found in the Quit case, the default value is being written out for 'Data Out'. So I just wired the wire through the Quit case from the input to the output,

Dang another dumb simple one, but again my code hid this bug since in my implementation I replaced the Diagram Editor with a simple state machine, thinking performance could be better.

---

@ssdet

Do you know how I can set up periodic CAN messages? I tried looking at the other Vector CAN VIs you have and also at the 15765 Class to see if there was a periodic property I can set to True and set the rate in millisec, but I couldnt find it. I searched "periodic" in VxLapi.h to see if there's any function names or comments with this keyword but I couldn't find it..

---

Negatory.  The only hardware that supports periodic writing is NI XNet, and the PCI/PXI NI-CAN hardware.  Periodic retransmits on other hardware types require software to do the work, which isn't impossible it just takes more work.  The implementation I use at work does do that but took quite a bit of re-write and keeping track of other things, lots of refactoring.  This combined with the hardware abstraction layer I wrote really ballooned the project.  This is now something like 1,300+VIs, and something that can't be posted due to it being on the company time, where this initial release and clean up was on my free time.  That being said something simple can be done in your project, just with a while loop that keeps writing the same thing after so much time has gone by.

Preallocate versus Shared is a setting I struggle with sometimes.  If I know the scope of a VI then I can feel confident in making it preallocate since that causes less jitter, especially on RT hardware.  In this setting there is no need to check the pool of clones and no extra work in creating or destroying another reference if one is needed.  In most cases the change is so insignificant it doesn't matter either way and I'm surprised to hear you had such a large difference in shared versus preallocate.  Remember a new clone on preallocate doesn't pop up every time you call a VI, it is every time you call a VI from a new unique call stack and instance.  If you call the same VI in a while loop over and over it will use the same preallocated clone.

[ssdet]

> The implementation I use at work does do that but took quite a bit of re-write and keeping track of other things, lots of refactoring.  This combined with the hardware abstraction layer I wrote really ballooned the project.  This is now something like 1,300+VIs, and something that can't be posted due to it being on the company time, where this initial release and clean up was on my free time.

I see, thanks for the clarification. I'm glad you made this free work available for others. 

> That being said something simple can be done in your project, just with a while loop that keeps writing the same thing after so much time has gone by.

Yea, I'll have to think up of something like that with the ability to enable/disable the messages on a specific CAN channel.

> I'm surprised to hear you had such a large difference in shared versus preallocate.

Indeed I was using asynchronous starts and I think that probably causes allocation of new memory.

> Remember a new clone on preallocate doesn't pop up every time you call a VI, it is every time you call a VI from a new unique call stack and instance.  If you call the same VI in a while loop over and over it will use the same preallocated clone.

Good to know. I'll keep that in mind.

[ssdet]

hi Hooovahh

I'm wondering if you might know whats causing this issue. When I send a certain unlock message with ID 155h via PCAN, the communication from the DUT works as shown in Option 1 below. But if I send that message using the Vector CAN vi, the DUT doesnt respond and there's a Timeout error as shown in Option 2. Do you know why this could be? I tried using the Flush Transmit Que vi, and tried setting the options of the 155h message to Extended and Echo on. It seems like there's a problem with the 155h message sent via the Vector VI because an external Application that uses 15765 also doesn't see a response from the DUT. I'm thinking that as long as I send out a specific message to the DUT, it should respond. My understanding of CAN is pretty basic as you can guess. I attached the VI I'm using.

; Message Number
; | Time Offset (ms)
; | | Type
; | | | ID (hex)
; | | | | Data Length
; | | | | | Data Bytes (hex) ...
; | | | | | |
;---+-- ----+---- --+-- ----+--- + -+ -- -- -- -- -- -- --
OPTION 1: Used P-CAN to send the 145h message:
4) 25742.5 Tx     0155 8 45 60 00 00 00 00 00 30 - Sent via PCAN 
5) 27074.5 Rx 14DAAAAA 8 10 08 2C FA 01 00 00 00 - Sent via Vector 15765 
6) 27081.1 Rx 14DABBBB 8 30 00 0A 00 00 00 00 00 - DUT responds as expected
7) 27081.6 Rx 14DAAAAA 8 21 01 01 00 00 00 00 00 - rest of the communication works as expected.

OPTION 2: Used Vector CAN to send the 155h message: 
2) 9445.7  Rx     0155 8 45 60 00 00 00 00 00 30 - Sent via Vector CAN (no response required from DUT) 
3) 10448.1 Rx 14DAAAAA 8 10 08 2C FA 01 00 00 00 - Sent via Vector 15765 
     No response from DUT and ECU timeout error generated

[Hooovahh]

This is either a setup issue, or a part specific one.  You say you are unlocking with 155, but in the text file it says PCAN is using 145, which is it?  It is possible that there are other things need to get the part to be ready to be unlocked but the ECU should still respond.  I'd say it is possible the part went to sleep, or is it an issue with PCAN using extended when Vector isn't?  That information wasn't shown in your log.  What is the wiring like, do you have the same resistor setup?  Is the Vector plugged into a node right next to PCAN or somewhere else?  Does PCAN insert a 120 ohm when on but not when off?  Generally it is as you said.  As long as the ECU sees a message on the expected ID it is supposed to respond with something even if it is a negative response.

[ssdet]

Thank you so much! It was indeed a Part issue. It needed another Send of the same frame for it to work and I'm so relaxed now that its working. Your reply was helpful and I went through the items you mentioned and took a closer look. Thanks so much again. Regarding the wiring yes its the same resistor setup.

[ssdet]

hi Hoovah, I want to make the updated 15765 vis available here so others can benefit from the work you and I did (what I did of course was really minor compared to what you've done). Should I zip the user.lib and menu folders and upload it here? That will be the easiest for me. Its from Labview 2014 and its about 15MB. I dont know how to make a package. I don't remember the state of your last upload. Let me know what I should do.