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

[StephenB]

v14 of the add-on is posted and brings these changes and known issues:

KNOWN ISSUES

1. If the workspace is open with a field or curve control as well as a graph and you select run, deploy, or connect. Rarely, the system can pause and then report a target sync error. If you close the workspace and reopen it, everything works fine.
2. Automatic connection handling does not work if there are no measurements added to the system definition. Add atleast one.
3. No notification to the user is given if reads (higher priority) are preventing writes from completing
4. Clicking on the custom device inside the system explorer marks your system definition as *dirty* with an unsaved change even if you didn't change anything

CHANGE LOG

• <Bug> The a2l file and seedkeys will no longer redownload to the target on every deploy. This should greatly speed deployment
• <Change> reads from the ECU are now higher priority than writes. If your writes aren't going through... it may be because the bus is saturated with reads
• <Bug> Fixed several bugs preventing the operating of more than one custom device on a single target
• <Bug> The custom device LLB will no longer redownload itself to the target on every deploy. This should greatly speed deployment
• <Feature> All LLBs are significantly smaller in size
• <Change> The default read mode for measurements is now polling. While this is less performance, this guarantees the device will work out of the box for people that do not have a DAQ list set up in their A2L. If you have been using the default DAQ list mode and never explicitly clicked to change to DAQ list mode... you will now be defaulting to polling mode... so be aware and change back if needed.
• <Feature> Improved system explorer, workspace control, API and real-time performance. The largest performance increase will be seen in the custom device execution
• <Change> The automatic reconnect feature relies on the DLLs provided with the add on, make sure to follow the updated installation steps noted in the readme.txt
• <Bug> <Change> Item writes to the ECU are now done with a change tolerance. The change tolerance is specified on the main page of the custom device and defaults to 1E-6. This should prevent erroneous writes to the ECU when very very small value changes happen just due to double precision floating point representation.
• <Bug> Errors reported to console and to log file no longer cause the NI VeriStand engine to go late
• <Bug> Connecting and disconnecting from the ECU (now automatic) no longer causes the NI VeriStand engine to go late or hang
• <Feature> The custom device now handles connect and disconnection from the ECU more gracefully and automatically. While running, it will always attempt to connect to the ECU and report the current connection status.
• <Change> the custom device will now handle connection to the ECU automatically with no explicit control from the user. the connect? channel no longer has any effect and it is noted as deprecated
• <Bug> Fixed a problem with the field workspace control incorrectly displaying and editing data if the field had been added to the system definition as channels.
• <Feature> Added System Definition API examples.
• <Feature> Added a new API, the XCP CCP Add-On System Definition API. It allows configuring the XCP and CCP Master Custom device without using the system explorer.
• <Change> API Calls are now inside LabVIEW libraries to facilitate more modularity. This shouldn't cause existing code to break.

[Lucabeer]

Ok, we installed v14... and we have mixed results!

The first experiment we made was a SUCCESS! We added ONE variable to the DAQ list (engine RPMs), acquired in angular task, and it worked like a charm. Nice real time plotting, no problems at all. It was the first time we got such a result: the same settings with v13 and running on the PXI hardware had always been a failure.

So far so good.

We tried adding a calibration (a map) to the system definition, we re-deployed the experiment... and we got the usual error code.

We removed the map from the system definition, thinking that it was causing trouble... and again, no communication, no plotting, and the usual error code. We powered off the ECU and powered it back on for a full reset, but again... to no effect.

Here attached is the log from the ftp on the device: it is very huge, but very repetitive so it zipped well. Is it so big because it is an incremental file?

And one more question... Is it possibile to specify more than one DAQ list at the same time? For example one at 20ms and one in angular task? From what I have seen, it looks like it isn't, right?

[StephenB]

Wow that is a huge error log. Can you FTP in to the target and delete the log so it starts at size 0 again, then try the same thing and attach that error log?

This one contains very old information at this point, and I'd like to see what errors are thrown with the v14 add on.

Thanks for the patience!

[StephenB]

And yes, right now there is only one measurement read loop in the custom device... so you can only pick one rate. I've had multiple requests for different rates for different measurements... but I haven't had the time to invest in that yet. For most people it isn't a show-stopper issue for them. Is this a big issue for you?

Remember you only need to add the characteristics and measurements to the system definition that you want available to the NI VeriStand engine (to map to models, hardware, to graph, etc). You can still read any measurement and characteristic from the workspace, even if it's not added to the system definition, with the custom workspace objects and the XCP and CCP Master Execution API.

[Lucabeer]

Well, having multiple rates (one DAQ list for each rate) would be exactly what we are looking for... but maybe we could give a hand in future to help implementing this feature when we'll have solved our problems and gained some experience on the system (we are actually quite new in the NI world, and we are experimenting a bit with Labview/Veristand/Teststand on different fronts!).

And now some update on the problem...

We have deleted the old log file, and started a new one. It looks like the problem is intermittent... Some times everything works (either in polling or DAQ mode: it doesn't seem to make a difference since so far we have just experimented with 1 or 2 variables at a time and thus the bus load is negligible), some times it doesn't. Sometimes we stop/undeploy a perfectly working experiment, return after 5 minutes, deploy again the same exact project we had been used a few minutes before... and it doesn't seem to work.

At times, we also notice that the PXI system seems to get "stuck" and unresponsive to a "connect" request from Veristand. Sometimes it fiexes by itself, some other times we've had to turn the machine off and reboot it.

Here are the log files from this morning, anyway...

[Lucabeer]

I would like to be add more info...

On the same PXI hardware, we are also running other stuff toghether with the XCP and CCP Master Add-On.

Our goal is to build a hardware in the loop system for testing ECUs, and so far we have successfully created Veristand applications for creating stimuli to the ECU. From the PXI (equipped with analogue and digital output cards, and a few FPGAs) we are providing the ECU with engine rpms, feedback from actuators, virtual pressure and temperature sensors: all these things are now output by our system and work fine.

Maybe this helps in getting a better idea of our configuration: I didn't want you to think that we are running only the Add-On on this machine... we actually have a lot of other processes going on in the background, although no one of them uses CAN: only analogue/digital outputs from dedicated cards and FPGAs... The CAN card is reserved for CCP comunication, and we seem to still have plenty of "processing power" judging from the console panel of the hardware...

[StephenB]

Thanks for the additional background. I appologize for the issues with this add-on and I appreciate your patience. I've noticed from your error log that I'm failing to correctly report errors for a specific item, hence the blank line right underneath the specific item line the error log. This probably isn't what is causing the problem as its simply reporting, but I've updated the custom device to 14.1 to address this issue.

The change log:

<Bug> Partially resolved known issue #2, the auto connection handling will now work if you have either a char or a measurement added... but you have to have one of either type
<Bug> Fixed a problem where specific item error information was not reported in the error log

From what I see and what you describe, I'm concerned you don't have a good installation of the add on. I feel you might have things mixed up from old versions and new versions. Notably, the hanging of the target. I've seen this happen if you don't have the updated ECUMC dll provided with the add on installed on the target.

I suggest cleaning out your current install of the add on and reinstalling it. Follow these steps:

1. FTP in to the target by opening windows explorer (windows key + e) and typing ftp://<ip>
2. Navigate to /ni-rt/NIVeriStand2010/Custom Devices/
3. Delete the XCP and CCP master folder
4. Navigate to <Public Documents>/National Instruments/NI VeriStand 2010/Custom Devices (on your computer)
5. Delete the XCP and CCP master folder
6. Delete the Custom Device XCP and CCP Master.xml file
7. Navigate to <Public Documents>/National Instruments/NI VeriStand 2010/Display Templates
8. Delete any files that start with "XCP", there should be 5
9. Download and unzip the XCP and CCP Master Add-on v14.1
10. Download and install ECU MC toolkit 2.1.5 (if you haven't already, you can check the software version in MAX under software)
11. Rename the existing "niemcc.dll" in "<Windows>\System32" to "niemcc.dll.bak"
12. Unzip the provided "niemcc_win32.zip" into "<Windows>\System32"
13. Rename the existing "niemcc.dll" and "niemcc.out" in "<Program Files>\National Instruments\RT Images\ECU Measurement and Calibration Toolkit\2.1.5.3.1" to "niemcc.dll.bak" and "niemcc.out.bak"
14. Unzip the provided "niemcc_pharlap.zip" and "niemcc_vxworks.zip" into "<Program Files>\National Instruments\RT Images\ECU Measurement and Calibration Toolkit\2.1.5.3.1"
15. If you are using an RT target, Open Measurement and Automation Explorer and install or reinstall the ECUMC toolkit support to your RT target.

That should do a completly clean install. Try that out with a brand new blank system defintion. Can you try these tests:

1. Just 1 characteristic added first deploy
2. Redeploy the same system definition as #1
3. Just 1 measurement added first deploy
4. Redeploy the same system definition as #3
5. 1 Characteristic and 1 Measurement added
6. Redeploy the same system definition as #5

[Lucabeer]

Well, it looks like the suggestion of going "clean slate" was good! Now at least we can deploy/undeploy as many times as we want without the communication with the RT target freezing and requiring for a reboot...

We tried the sequence you suggested:

Just 1 characteristic added first deploy

Ok, everything great: we can write and read the characteristic

Redeploy the same system definition as #1

Ditto.

Just 1 measurement added first deploy

Great: we can read the measurement, and graph it.

Redeploy the same system definition as #3

Here the bad news start... The usual error code, and we can no longer read the measurement or graph it.

1 Characteristic and 1 Measurement added

The same... From the previous step, CCP communication seems to have died.

Here attached is the log file...

Thank you very much for your support!

[StephenB]

Hmm... I just set up a system with a PXI-8513 connected to a CCP slave, then deployed a sysdef with a single measurement in it. Worked great. I undeployed and redeployed several times and it always worked.

I'm wondering if your CCP slave has a specific requirement about a shutdown sequence or a problem disconnecting, as it seems to be specific to your slave.

Can you try reproducing the issue with just the labview example "" in the example finder? That example does pretty much what the custom device does.

Thanks,

[Lucabeer]

Our CAN card is a NIX-8512 with the latest drivers.

Today we will try using a CAN analyzer to see what goes on the bus to check how the disconnect sequence is handled, and we can also try the labview example...