XCP and CCP Master Add-On for NI VeriStand feedback.

[Lucabeer]

Our ECU HW is a 100% proprietary one, not from a commercial brand such as Mototron, Bosch or Marelli. The software implementation of CCP in the ECU is also proprietary, although as a matter of fact it is derived by Vector. We have been successfully using it for years with ETAS Inca when we can't afford their proprietary ETK and so we need CCP.

We'll be looking forward to v15, then! Thank you very much!

[StephenB]

OK I think I fixed the measurements bug. I just tested it and it works. Thankfully it was a very trivial fix, a simple oversight.

I'm going to put in a few more fixes in this release and put out 14.3 ASAP. Please note, I haven't found a fix for the connection problem yet. I have to rely on R&D for that fix as its a problem with the toolkit. So until then, you might want to run in NI-CAN mode (don't check NI-XNET on the main configuration page)

Thanks for your patience,

[StephenB]

I just posted 14.3 with this change list:

<Bug> Fixed a major bug that caused the device to error and throw -301031 if a measurement was added to the system definition and its value changed rapidly during deployment	14.3
<Bug> Fixed a bug with the curve workspace object where it would attempt to read an item that no longer existed on the target if you changed A2L files	14.3
<Bug> Increased the TCP timeouts internally used by the execution API. The previous timeout was too short for slower CCP CAN networks causing workspace controls and API calls to error	14.3

Try that out. Note that the API, the custom device LLBs, and the workspace controls all changed in this update, so you will want to copy over all of them.

Also note this does not fix the bug where NI-XNET mode doesn't seem to work properly with some ECUs. I'm still working on that. Follow my previously posted steps to use NI-CAN compatibility mode if needed.

[Lucabeer]

Ok, we tried 14.3 and without NI-XNET it seems to work fine! With NI-XNET, as expected it doesn't work... but that's already a huge improvement!

One question, though: when running without NI-XNET, we still got an error code. It was "073094665". We are wondering what kind of error that is, since everything seemed fine to us: multiple variable plotted at the same time, characteristics edited without problems, etc. etc. :mansurprised:

[StephenB]

Sounds great!

I think that error code is 1073094665 and the 1 is being clipped off by the workspace control. Non negative code's are just warnings. Negative codes are errors. The explination for this is:

NI-CAN:  (Hex 0x3FF62009) The data returned from this Read matches the data returned from the previous call to Read.  Solutions: If you merely want the most recent data, ignore this warning

So no worries! You also might want to reduce your read rates if you can.

[StephenB]

I just heard back from R&D about the connection issue.

There seems to be a simple reason for it. If your network contains only two CAN nodes (the ECU and the CAN port on the RT chassis) when you stop the CAN port on the RT chassis, there is no other node that acknowledges the CAN frames sent by the ECU. As a result of this the ECU goes bus off after a while. When you then start the communication on the CAN port on the RT chassis, the ECU might need some time to recover from this bus off state before it can accept CCP commands. Unfortunately it seems that the CONNECT command is sent out by the toolkit before the ECU reaches that state so that the CONNECT command is not acknowledged by the ECU, However, sometimes it works. This results in the inconsistent results error you see when you are running.

The time difference between it working and not working is really just a few ms... so if you switch to the non-NI-XNET code path in the custom device... the timing is just different enough to make sure it works. In the future, either the toolkit will try to work around this, or I'll put a work around into the custom device.

[Lucabeer]

We are doing a little brainstorming here at the office right now, and the main objection is this: in the CAN recordings made with our Analyzer, we have always seen a "DISCONNECT" command from the RT chassis, and the relative "acknowledged" from the ECU...  so why should the ECU stay in "bus off" after it was correctly disconnected?

[StephenB]

Is the analyzer set to listen only mode, therefore not acknowledging CAN frames?

[Lucabeer]

Yes, only listen mode. We also tried to set it the other way, but no noticeable difference.

[Lucabeer]

We have been experimenting a bit in the meanwhile, and one thing that keeps puzzling us is the randomness of the "malfunction".

Today, for example, we seem to be having problems on NI-XNET even when using "polling" mode instead of "DAQ list" to communicate...

Does this timing bug you found in the NI-XNET drivers affect polling measurements, too?