SET DAQ LIST MODE xcp command sometimes sends bogus value, returns error -301072 on start

[croohcifer]

Hi all!

I'm using ECU MC 18.5.  Here's a hugely simplified version of my code that reproduces what I'm about to describe:

Note that I do not explicitly specify an event channel for my DAQ List, but the behavior I'm about to describe replicates even if I do specify an event channel.

Basically, most of the time the code above works.  I can start the DAQ List and read data from it and stop it with no error.  (I got rid of the DAQ List read and stop VIs in my example because they're unnecessary to replicate the problem.)  Sometimes, however, when I start the DAQ List, the Start VI returns a nebulous -301072 "Parameter out of range" error.  I looked at the XCP Trace and found something interesting:

Every time I don't get the error and the code works, I see that the "Event" parameter value in the SET DAQ LIST MODE command is 0x1, which I'm assuming is the default value when you don't specify an event channel explicitly.  0x1 is a valid event channel defined in my A2L file.  (When I do specify a alternate valid event channel explicitly, I do see that "Event" parameter value reflect what I chose, but I still intermittently get the issue the follows.)  When I get the error in LabVIEW, the log shows an "Event" parameter value of 0x127 or 0x78.  I've tested by setting my VI to run continuously, and after receiving 20 such errors, those were the only two "bad" values I ever saw in the XCP trace.  My A2L file does not define either one of these values, so I'm not sure why the ECU API is selecting these values.

If I read the event channel string property before and after calling Start, it's the same before and after when Start doesn't throw an error.  When I do get an error on Start, the event channel I read back is the same as what I set before start and blank after calling Start.  This seems to indicate that the Start function is somehow selecting a nonexisting event channel.

Could I be doing something wrong, or is this a bug?  I'm installing 19.0 to test if that fixed it, but I didn't see it in the readme as a known issue or bug fix.

Thanks,

David

[croohcifer]

Confirmed that this is still an issue in ECU MC 19.0.

[tolltroll]

While trying to reproduce this case, our development team encountered a different bug in ECU MC which made it impossible to reproduce your issue. This bug is now fixed in 19.5, and with it in place, we can't reproduce this issue.

There is some probability that it is the same bug which looked different on your side (we saw an exception), but there is still a possibility that there is another problem. We suspect it may be with the A2L file.

We can create a patch and let you try it, but if this doesn’t work we'd like to get your A2L file so we can test with it on our side. (Naturally you can send this in privately.)

We also need a definitive version of ECU MC in either case. I see that you tested 18.5 and 19.0, which are you currently using?

Nick

National Instruments

[croohcifer]

Hi Nick,

Sounds promising!  I currently have 19.0 installed on my development machine.  Please send the patch my way, and I can test it out.

Thanks,

David

[croohcifer · Accepted solution]

Just wanted to tie up this discussion.  Many thanks to Nick and NI R&D for pointing out that our ECU was responding to an XCP command incorrectly, which was causing the NI ECU MC Toolkit to occasionally select an invalid event channel. 

There isn't a bug in the NI software that caused this issue, though it would have been helpful if the NI toolkit alerted users (through warning or error) that the slave's response was ill-formed.  It sounds like adding a feature like this is on NI's radar, which is good to hear!