Flow control message not long enough

[eventsb]

Hi Brian,

First of all I want to say thank you for taking the time to build this library, it is incredibly useful.

I wanted to point out a small issue I am having regarding multiframe messages. I am not sure if this is due to J2534Sharp or the underlying Drewtech driver, but when I try to receive a multiframe message, the program will send a flow control message of "30 00 00". Unfortunately it seems this particular module I am working with does not accept that as a proper flow control message, it is expecting a complete 8 byte message, in other words it expects to see "30 00 00 00 00 00 00 00".

Is this something that is able to be modified in J2534Sharp? Or do I need to look at the underlying DLL?

Thank you for your time.

[BrianHumlicek]

That’s a good question. Are you explicitly defining the flow control message or are you using the built in function?

Brian

[eventsb]

Built in.

[BrianHumlicek]

I expect you are using ISO15765, which generates the flow control messages below J2534Sharp. If so, I don't have any control over it. After a cursory look, it appears that the message 03 00 00 is a valid flow control message, so, it would seem that the issue is the module not following the ISO15765 standard.

An immediate option is to open a raw CAN connection and handle the ISO15765 layer in your application. This would allow you to create non-standard flow control messages. Although this would be a lot of effort, it will definitely accomplish what you want, and work on any 2534 device. Optionally, you may experiment with manually defining the flow control message and see if you can find a definition that will coax the underlying driver to create the message you want.

Mark Wine at Drewtech has been very helpful to me in the past, and might be able to offer a workaround, or at least some advice. If this is turns out to be a bug in Drewtech's implementation, they may be inclined to patch it and give you an update.

Beyond that, maybe there is a firmware update for this module that would alter this behavior.

Brian

[eventsb]

After doing some digging I noticed this paragraph on the Drewtech website:

Be aware, many engine controllers are sensitive to the format of the flow control message. Some controllers expect the messages to be zero-padded to a full 8 bytes, while others expect only the necessary data. Adjust the ISO15765_FRAME_PAD flag to match the expected behavior.

located here: http://www.drewtech.com/support/obd2.html

So it seems Drewtech is already aware of the behavior of some of these modules. I had already set the ISO15765_FRAME_PAD flag on my transmitted messages like so:

public void TransmitMsg(uint txTarget, ulong rxTarget, byte[] data)
{
    byte[] message = new byte[(data.Length + 4)];

    // build message to send
    message[0] = (byte)(txTarget >> 24);
    message[1] = (byte)(txTarget >> 16);
    message[2] = (byte)(txTarget >> 8);
    message[3] = (byte)(txTarget >> 0);
    data.CopyTo(message, 4);

    var txMsg = new Message(message, TxFlag.ISO15765_FRAME_PAD);

    m_j2534Interface.ClearRxBuffer();
    m_j2534Interface.SendMessage(txMsg);
}

And it was still not working. Then I realized I needed to also set the flag for the message filter, like so:

var msgFilter = new MessageFilter();
msgFilter.FilterType = Filter.FLOW_CONTROL_FILTER;
msgFilter.Mask = new byte[] { 0xff, 0xff, 0xff, 0xff };
msgFilter.Pattern = new byte[] { 0x00, 0x00, 0x07, 0xe8 };
msgFilter.FlowControl = new byte[] { 0x00, 0x00, 0x07, 0xe0 };
msgFilter.TxFlags = TxFlag.ISO15765_FRAME_PAD;
m_j2534Interface.StartMsgFilter(msgFilter);

And now it is working flawlessly. Thank you! This issue is now resolved.

[BrianHumlicek]

Now that you mention it, I believe I remember reading about that. I'm glad its working for you.

You can tidy up your code by doing the following.

var msgFilter = new MessageFilter(UserFilterType.STANDARDISO15765, new byte[] { 0x00, 0x00, 0x07, 0xE0 }); msgFilter.TxFlags = TxFlag.ISO15765_FRAME_PAD; m_j2534Interface.StartMsgFilter(msgFilter);