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

[Lucabeer]

We have made a few tests... and what bugs us is that the behaviour of the system seems very little repeatable... Further investigation using both the Windows PC (with a dedicated CAN card) and the real-time platform, has made us notice that actually the problem appears in both cases... only on the real-time target it seems more frequent (at least that's our impression).

Two questions:

1) are you running in high speed CAN configuration, or low speed? (We can only do high speed, with the 8512/2 card)

2) the Labview example you are referring to, is part of the Add-On zip archive? Or is it something that comes default with the ECU and MC toolkit?

[StephenB]

I'm running at high speed.

This example comes with the ECU Measurement and calibration toolkit. You can find it with the example finder. So you will have to uninstall NI VeriStand from the target, and then run that example on the target with a LabVIEW project.

[Lucabeer]

Here are some results from the tests from our CAN analyzer...

CAN1_CharacteristicAndMeasurement

Here we had ONE characteristic and ONE measurement in the system definition (same ones as last week). We see two messages for CONNECT, and the relative acknowledge. Then an EXCHANGE_ID, and the relative ack. Then alternate UPLOAD and SET_MTA with the relative acks, which go on forever until at the end of the session we issue a DISCONNECT (and we get the ack)... The DAQ list wasn't even initialized!

CAN1_OnlyMeasurement

We removed the characteristic from the system definition. CONNECT, EXCHANGE_ID, UPLOAD, GET_DAQ_SIZE... and then after the acknowledge nothing else happens... The "master" does not issue any more commands, and the target of course stays silent. Apart from this... why does it issue an UPLOAD command?

CAN1_OnlyMeasurementOK_I (and _II and _III)

We turned off the whole system (real time platform, ECU, Veristand) and then turned it on again. In these three tests, everything worked fine. After the _III test... again the system got stuck, with same results as in the two previous "failure cases"...

And yet we seem to see nothing wrong on the CAN bus, which could justify the ECU getting stuck as if the communication has not been closed in a "kosher" way...

[Lucabeer]

Tomorrow we'll try the Labview example... thanks!

[StephenB]

Attached is a VI to try. It is pretty much exactly what the custom device is doing inside its measurement read loop. You will notice there is call to transmit the daq list to the ECU, that is what is causing the upload command.

You will have to change the inputs on the front panel to match your system.

Try running this a few times and see if it causes the same problem.

[Lucabeer]

We tried both with your attached Test Meas.vi, and with the ECU MC Advanced Calibration and Measurement.vi example provided with the toolkit.

Everything worked fine, even after multiple stop/restart sessions...

Please note that we only tried with CAN0 (the card on the PC), and not on the RT target.

What should we enter to work with CAN1 on the RT target? I guess, from the documentation, that it should be something like CCP:CAN1@.....  but we don't have a clue on what to write after the "@"...

[StephenB]

Thanks for checking that.

Do you have the LabVIEW Real Time Module? If so, follow these steps to try the VI on the RT target:

1. Open MAX and uninstall NI VeriStand from the target
2. Open LabVIEW and create a new project
3. Right click the project file inside the project explorer and say new -> targets and devices
4. Expand real-time PXI
5. Select your PXI and select OK, the target should now be in your project
6. Drag and drop test meas.vi under the target
7. Open up test meas.vi and run it

Note that the file path for the A2L file will now be for the target. So you will have to FTP in to the target and copy your A2L file somewhere. You can just put it on the root, so C:\mya2l.a2l

[StephenB]

I just hooked up a Mototron ECU that has a CCP slave in it and I'm seeing similar issues. Lots of error -301003.

I'll let you know if I figure it out.

[StephenB]

Low and behold, my Test Meas.vi has the exact same issue as the custom device with this Mototron ECU.

I have another customer using this with a company proprietary ECU and it works just fine. Would you happen to be using a Mototron ECU? I'll see if I can work around this and post a patch.

[StephenB]

OK. I've found a few bugs. I will be working on them to give you a fix ASAP. There is no need to do the LabVIEW test at this time, since I think what I have seen are the same things you're seeing.

My custom device fails to connect to a Mototron CCP slave in certain circumstances if I'm using an NI-XNET CAN card. Strangely, if I attach a bus monitor it works, or if you use the older NI-CAN products it works. I'm working with R&D to fix this, but in the mean time, if you're experiencing this, there is a workaround.

1. Install the NI-XNET Compatibility layer with Measurement and Automation Explorer to the target
2. When configuring the custom device inside system explorer, do not check NI-XNET, and pick your CAN port enumerating at 0. So if you have two CAN ports... the first one is CAN0. The second one is CAN1... etc.
3. Redeploy

The other problem is more serious and will require a new version of the custom device. If a measurement value is changing while the system definition is being deployed (CPUIdlePcnt for example), then the custom device will erroneously think the user has changed the value and will attempt to write this value change back to the ECU... which causes a write violation error and everything stops working. Strangely, this doesn't happen with my software simulated ECU... only my Mototron. I'll look into this asap.