Automotive Diagnostic Command Set USB Transfer Data Error

[Hooovahh]

The PNG snippets do work with some extra work, and I figured the previous VI was simple enough it didn't need a snippet (I just added a single VI that is on the palette).  That being said I think I see the problem.  You'll probably notice the Vector example has more than just a set baud but also Flush Queue and Start which to your credit you mentioned earlier but I didn't realize those were required.  Here is another go with those two things added.

And VI attached back saved but can't test cause I don't have 2014.  It should search and eventually find the VIs in the user.lib.

[ssdet]

hi Hooovahh

Progress! But first a quick summary of what I have to do. Basically I was told that I have to send this data with the appropriate CAN Id and I'll get a response:

  Send CAN ID: '14DAB2C0', data:  2E FE 01 00 0F AB CF FA A3 10 00 01 01

  Response CAN ID: '14DAB2C1', data: 6E FE 02

So all I know is that I have to send that long data packet 2E FE with the CAN ID and I have to be looking for a response which can be single or multi-frame. End of summary.

So when I added the Que Flush and Start you mentioned, now I have a packet on the line and there's a response from the DUT but then Labview doesn't send the next frames.

Here's whats on the traffic when I sniff it using a P-CAN:

13) 2905.7   Rx  14DAB2C0 8 10 08 2E FE 01 00 0F AB     <-- sent (first frame)
14) 2909.1   Rx  14DAB2C1 8 30 00 0A 00 00 00 00 00      <---received but not reported by Labview.

(The remaining frames for the remaining data 'CF FA A3 10 00 01 01' are not sent by Labview)

As you can see my device is using extended ID e.g. the Request ID looks something like this: 14DAB2C0 - the first digits are correct, I changed the last four. Previously you said I need to change the code to send/rec Extended IDs:

      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)

So I added the boolean in this file:

    _Hooovahh\CAN ISO 15765\Controls\Cluster - 15765 Settings_ISO.ctl

Then I routed the variable from this file:

     _Hooovahh\CAN ISO 15765\Public\Initialize ISO 15765_ISO.vi

And I used that value where I needed it. I think its working for Sending but I dont know what to do for Receiving. I went to this file but couldn't figure out where to make the change: \_Hooovahh\CAN Drivers\Vector CAN Drivers\CAN\CAN Receive_Driver.vi

Do you know where I should add the Boolean? I'm hoping once I add it, it will work. Or maybe I also didnt correctly implement the Boolean for sending.

One thing I noticed in the following file ....:

     \_Hooovahh\CAN Drivers\Vector CAN Drivers\type defs\Cluster - Event Flattened_Driver.ctl

.... was that 'Trans ID' is a U16 and when I tried to change it to U32 to accommodate extended IDs, the ID of the message that was sent out, was messed up so I reverted back to U16. Its possible that this doesn't need to be changed since you only talked about the Boolean which is present in the CAN frame data structure.

I fixed a minor error in this file:

   \_Hooovahh\CAN Drivers\Vector CAN Drivers\CAN\Utilities\Flatten CAN Transmit_Driver.vi

The mask used for the AND was missing one F, so now it has the correct value: 7FFF FFFF

Before the error it was cutting off one digit from the extended ID which starts with a 1 and has 8 digits so the message on the line was missing one digit.

I tried following your suggestions in the post where you talked about the Payload to use UDS read/Write VI's and when I do that, the first packet is different and Labview still doesnt send the remaining frames. I dont know what the correct VI to use is, whether its the UDS Read/Write or the Diagnostic Read/Write. I was only told I have to send that long CAN message.

I hope my DUT is working fine. It would be nice if there was a way to simulate a DUT where we can set up a reply/response ID and data for debugging. That way I would know my device is working. That would help in debugging.

Here's my snippet and I also attached the two files, the 2nd file is a sub-vi used in my main file and it converts a string to array of bytes (solution by altenbach).

[Hooovahh]

Glad you are making progress.  I think the Exendedness is the last of your issues.

So if you added the Extended boolean to the "Cluster - 15765 Settings_ISO.ctl" then you are on the right track.  This boolean then needs to make its way to the "Write First Or Single Frame" case in the "Read and Write Diagnostic State Machine_ISO.vi".  I suspect you did this since the data went out.  It needs to be bundled into the same bundle by name that has the Payload and Identifier (grow the bundle to be 3 in size, then wire to Extended).  To do this properly you also need to add the Extended input to the "ISO 15765 Transmit Blocks.vi".  Similarly we write frames there and need the Identifier, Payload, and Extended bundle by names in both the case 0 and Default case.  I think this is your problem.  You see you send the first frame, and then the state machine reads the flow control, but doesn't send the rest of the frames on that same ID.

As for reading of extended, there actually is a bug that will make this work.  Notice in the "Read Frames for ISO Reply.vi" that we look for a frame that is not an echo, and is the right ID but we never actually look at if it is extended or not.  So this means our code should read extended and non-extended as coming from the same location.  Since your ID is 29 bit it can only be extended and I see no issue with just reading all frames with that ID.  I'll look into adding extended functionality to the code for a future update.

[Hooovahh]

Just noticed also the Write Flow Control state in that state machine needs the Extended bit too.

EDIT: Darn another bug.  In the Write Chunk of Data State we call the ISO 15765 Transmit Block.vi.  This has an input that is unwired, it really should be set to required.  Wire from the Hardware Selection coming from the outside of the loop to the input of this subVI.  I'm working on the updates now but that will be pushed to the package first which you said you couldn't install.

Double Edit: Regarding the Trans ID.  This is something used internal to the XL Library wrapper and the flatten doesn't even use it.  Notice the CAN ID goes out on Data 0, Data 1, Data 2, and Data 3.  These 4 bytes are what contain the CAN ID.  Thanks for the ID filter catch.

[ssdet]

hi Hooovahh, thanks, I did these two edits now:

To do this properly you also need to add the Extended input to the "ISO 15765 Transmit Blocks.vi".  Similarly we write frames there and need the Identifier, Payload, and Extended bundle by names in both the case 0 and Default case.

...

In the Write Chunk of Data State we call the ISO 15765 Transmit Block.vi.  This has an input that is unwired, it really should be set to required.  Wire from the Hardware Selection coming from the outside of the loop to the input of this subVI.

But I still wasnt able to send the next frames so I did some debugging in the main State machine (\CAN ISO 15765\Core\Read and Write Diagnostic State Machine_ISO.vi). It now correctly reads the flow control frame and it enters the case for 'Process Read'. Over there the Enum output of the smaller case in the middle is "Write Chunk of Data". This output is fed to a small While loop and it exits the while loop with 'Done' so it doesn't go to the case for 'Write Chunk of Data'. I was thinking I could take that output and wire it directly to the exit of the main State diagram. Or maybe the data type of the Enum wouldnt match if I did that. But my OpenG Toolkit wont install so I wasnt able to edit that While loop or even remove it. I'll see what I can do.

Similar to the ID filter for Sending, this was also the case for receiving. In this file ...

        \CAN Drivers\Vector CAN Drivers\CAN\Utilities\Unflatten CAN Receive_Driver.vi

...I changed b111 to b11111 at the AND gate, so it allows extended ID's to pass through. Before that it was truncating the last digit of the extended ID.

[ssdet]

I missed your comment here so I did that:

    Just noticed also the Write Flow Control state in that state machine needs the Extended bit too.

I also added the extended bit in the 'Write Chunk of Data" to this vi (ISO 15765 Transmit Blocks_ISO.vi) which now has the needed Extended bit input.

[Hooovahh]

Edit: Dang another bug, not sure how I haven't seen these.  My internal use of them uses a hardware abstracted layer to do the hardware selection, and I replaced the state machine with a normal one, where this one was good for making the diagram.  Give me a few minutes and I think I'll have the fix.

Double Edit:  Okay here is the fix.  Open the control 

"\CAN ISO 15765\Controls\Enum - ISO State Machine.ctl"

Then edit the enum.  Right click and pick Edit Items.  "Select the Write Chunk Of Data" entry which should be value 8.  Edit the text to be "Reply Is Flow Control".  Then click OK, and save the control.  I admit this was a weird way of selecting the state to go to but in the confines of the state diagram editor this is how I came up with an enum selecting an enum.

Tripple Edit: Dang other issues.  I'll just upload the modified files.

[Hooovahh]

Okay here we are again, hopefully this is the last of it.  Re-download this zip which has been updated.  Copy over the CAN ISO 15765 folder replacing the ones in your user.lib.  This is the only folder that has been updated.  I didn't get to making the other Vector specific bug fixes you found.  This should add the Extended ID input, and have the bug fixes for hardware, and state machine issues I mentioned earlier.  I haven't updated the package yet but will be.

[ssdet]

hi Hooovahh, thanks for the new zip file. I copied it over, inserted the other minor fixes which were:

\CAN Drivers\Vector CAN Drivers\CAN\Utilities\Unflatten CAN Receive_Driver.vi ---- changed b111 to b11111 at the AND gate to allow extended IDs.

\CAN Drivers\Vector CAN Drivers\CAN\Utilities\Flatten CAN Transmit_Driver.vi ---- Update the mask for the AND gate to be '7FFFFFFF' (one extra F to cover extended IDs)

The data I was trying to send was: 2EFE01ABCDEFA1A2A3

The first packet it sends is: 14DA A1A1 -- 8 -- 10 09 2E FE    01 AB CD EF   (sent to DUT)

So the data remaining to be sent is 'A1A2A3'

I still didnt get the remaining frames sent sent so I debugged further. The reply from the DUT was:

14DA A1B2   -- 8 --  30 00 0A 00    00 00 00 00  (received by DUT)

From the reply, the block size is 0. When this 0 is fed into the following file ...

    \CAN ISO 15765\Core\Utilities\ISO 15765 Transmit Blocks_ISO.vi

...It goes to a Min/Max function so the output of that is a 0 which is used for the index of the For Loop which contains 'Write Single Frame ISO', so that loops doesnt run the and VI exits.

I was thinking of using a +1 before the Index but I dont know if that would mess up anything else so I didnt do that.

I wonder if this logic would work: If block size = 0, then use the value calculated by looking at the size of the DataIn array. Otherwise use the Min/Max function.

[Hooovahh]

---

@ssdet

I wonder if this logic would work: If block size = 0, then use the value calculated by looking at the size of the DataIn array. Otherwise use the Min/Max function.

---

This is absolutely the logic to be used.  If Block Size is 0 then that is the device saying there is no limit on the number of frames it can read at once.  I've never seen an actual ECU behave this way so I never tested it.  I'll be making an update and again posting it, but for now if you want to try it out just change the code so if the Block Size is zero, use the value going into the Y input of the Min Max (bottom) and if it not equal to zero, to use the output of the Min Max function.