"Start All DAQ Lists" only sends SELECT command on first call. This violates the XCP spec and causes subsequent read timeouts with error -301096.

[croohcifer]

Hi all,

I think I have found a bug in the ECU MC toolkit.  I have observed it in 18.5 and 19.0.  If you create a DAQ list (or many DAQ lists) and then start/stop the task(s) using the "Start DAQ List" and "Stop DAQ List" options, you can start/read/stop the task(s) as many times as you like.  The problem with this is that the DAQ lists are not synchronized.  To synchronize them, you can use "Start All DAQ Lists" and "Stop All DAQ Lists" options after having configured multiple DAQ lists.  With these options, I can start/read/stop once successfully, and the data is synchronized.  On the second time, the read times out with error -301096.

I figured out that the first time "Start All DAQ Lists" is called, the XCP trace log shows this:

In other words, the appropriate DAQ list(s) is(/are) selected and then are started with the START_STOP_SYNCH command.  Every subsequent time I call "Start All DAQ Lists", I only see this:

In other words, the ECU MC API is not sending the START_STOP_DAQ_LIST command to select the DAQ list(s) on all subsequent runs.  Correspondingly, I don't see any data returned from my ECU.  If I use "MC Generic.vi" to manually add the correctly formed START_STOP_DAQ_LIST command before calling all subsequent "Start All DAQ Lists" calls, my ECU returns data.

I believe this is a bug in the ECU MC API and that it should be sending the START_STOP_DAQ_LIST command every time you call "Start All DAQ Lists" based on the fact that ASAM's XCP specification states that the ECU should reset its DAQ List's "selected" status every time START_STOP_SYNCH is called:

Here's a VI that demonstrates the behavior.  It is configured to use a single DAQ List and capture two data records:

If you run it with both booleans set to FALSE, the code uses "Start DAQ List" and "Stop DAQ List" options.  The code captures two data records with no issue, and the XCP trace log shows that a DAQ list is selected before every start, as in my first screenshot above.  If you then set "Use Start/Stop All Commands" to TRUE, you'll see that the code captures the first record with no issue and then times out on the second iteration's read VI.  If you then set the "Enable Workaround" boolean to TRUE, I manually add in the START_STOP_DAQ_LIST command with the "select" option for all but the first loop iteration.  You can now read multiple records with no issue.

Another workaround is to just initialize and clear the DAQ lists every time you want to capture a new record.  Normally, I'd advise against that since you don't want to open/close instrument references over and over, but in this case initializing/closing DAQ lists only sends commands on an existing instrument interface without closing and reopening it.  Thus, it's probably not all that bad from a performance perspective, though I haven't characterized it.

Note above that I'm only using one DAQ list, which makes the Start/Stop All commands unnecessary, but this issue replicates with multiple DAQ lists, which is my main use case.  I just wanted to post the simplest reproducing case, which is why I pared it down to one.

I posted here to document the fix for subsequent users, but ultimately I'd like NI to weigh in and let us know if this is a bug and, if so, to please provide the CAR number.  Also, please let me know if I'm misunderstanding the behavior and have just done something silly!

Thanks,

David

[croohcifer]

For some reason the snippet in my post doesn't work.  I've attached the code here.

[WaldemarM]

Hi David,

You have to call Prepare For Start All before calling Start All DAQ Lists.

Check this part of the ECUMC documentation:

Prepare For Start All

Prepares DAQ or STIM lists to be started by only one command. This is useful when multiple DAQ or STIM lists are used with the same ECU. After preparing the DAQ/STIM lists with this command, use the same VI with the mode Start All DAQ Lists to start all lists at the same time.

Start All DAQ Lists

Starts all previously prepared DAQ or STIM lists at the same time.

I hope this helps,

Waldemar

[croohcifer]

Hi Waldemar,

Yes, I saw this in the documentation, but it makes no difference in the behavior, and if you step through the code while looking at the XCP trace, Prepare All for Start does no XCP communication whatsoever with the ECU on the second run.  It appears to be a no-op from the XCP communications perspective, though I don't know if it does anything in the driver layer.  I have already explained this to the AE I'm working with on this issue.

Thanks,

David

[tolltroll]

Hey David,

I've been working on this service request but I'll just comment here: Can you post the VI that calls Prepare for Start All? I'd like to take a look at your implementation and see if we can reproduce that behavior here.

Also, can you confirm that the XCP logs are unchanged when Prepare for Start All is used? If so, we already have these on hand. But if they're different, I'd like to see how.

Thanks,

Nick

National Instruments

[croohcifer]

Hi Nick,

Please see the attached code that includes a boolean that enables "Prepare for Start All".  When "Use Prepare for Start All" and "Use Start/Stop All Commands" are TRUE and "Enable Workaround" is FALSE, MC DAQ Read times out on the second iteration of the FOR loop.  When I then set "Enable Workaround" to TRUE, both iterations work as they should.

If "Use Start/Stop All Commans" is TRUE and "Enable Workaround" is FALSE, the state of "Use Prepare for Start All" (TRUE or FALSE) doesn't change the commands sent in the XCP trace, and the read always times out on the second loop iteration.  The only things that change when I diff the two traces in a text editor are the message timestamps and the data payload when my ECU sends DAQ data back the first time the FOR loop executes.  Both of these differences are expected.  Let me know if seeing these traces would be valuable to you, and I'll check with our software team if there's anything proprietary I'd have to strip out.  That said, I'd hope that with the attached code it'd be trivial for NI to reproduce if it really is a bug and not just me using the API incorrectly.

Best,

David

[croohcifer]

Hi Nick,

Any news on this issue and whether NI was able to reproduce it?

Thanks!

David