09-06-2017 04:27 PM - edited 09-06-2017 04:33 PM
I am new to ECUMC and CAN communication. I am using a NI-9862 in a cDAQ-9181 and communicating with an OEM ECU. I have a parameter that is an array of dimension 4 X 1 but it is of the Measurement type parameter instead of the Characteristic type parameter. I do not see a way to read an array in the Measurement category. All other parameters that meet the standard data type criteria in ECUMC seem to work as desired. I was supplied with a basic VI set from the ECU manufacturer for communication to their ECU, however, they do not use the ECUMC. They have incorporated their own dll, presumably written in some form of C, and it does not lend itself being incorporated into other VI's.
09-07-2017 10:30 AM
You should take a look at the ECUMC Manual linked below. After skimming through the Measurement section it looks like you should be able to use a DAQ Read within a Measurement Task to pull information from that parameter type.
ECU Measurement and Calibration Toolkit User Manual - National Instruments:
http://www.ni.com/pdf/manuals/371601j.pdf
09-08-2017 04:46 PM
I have look through the manual and have determined that the DAQ Read vi only supports a single value per channel per sample. This was confirmed by NI tech support and now I am trying to find a way around this. Has anyone else run into this issue, and found an alternative?
09-25-2017 08:29 AM
Kirk, what type of Database files are you using? Is this using .DBC or .A2L files? The conversion is relatively simple as long as you know the beginning address, type and endian.
09-26-2017 06:49 AM
Did you need to enter the below parameters in order to communicate with the ECU:
CRO ID CAN identifier of the Command Receive Object (CRO) (example:119d)
Data Transfer Object A message sent from the slave device to the master device (Command
Return Message, Event Message, or Data Acquisition Message).
DTO ID CAN identifier of the DTO. (example:23d)
Station Address (example:81d)
A property which specifies an address to generate a logical point-to-point
connection with a selected slave station for the master-slave command
protocol. One ECU may support several station addresses
09-29-2017 09:42 AM
Hi,
I am just facing the same problem. I have to measure some vectors from an ECU and there is no way to make Labview understand this is a vector. it is working fine with all the single parameters (both reading and writing).
to be more specific, if for example I have a 4x1 measurement array called "myvec", the right way to access the single components is (according to the standard and a2l): myvec[x][x]
for each measurement vairable in the a2l file there is a list of available properties labview can access with the VI get properties (f.e. max and min value, if it is a floating point and so on). among these, for the array a property called MATRIX_DIM is specified. if I try to get some properties of "myvec" from Labview he replies positively, meaning it is aware of the existence of this measurement. but there is no option to select "vector/matrix dimension" from the property list in labview. if I try to measure "myvec" labview gets only the first element of the array.
unfortunately, if I try to type something like "myvec[1][1]" or anything including square brackets to index, labview does not measure anything, because it is looking for the variable myvec[1][1] (which does not exists).
it just seems labview does not even consider the existence of measurement arrays (I can also read data with dspace controldesk which instead works just fine with the same a2l).
I would be extremely grateful to know if someone else has encountered the same problem and/or if there is any solution.
09-29-2017 09:56 AM - edited 09-29-2017 10:01 AM
We had the same issue years ago. It is not a LabVIEW issue. Convert your "[" and "]" to "_" in your A2L files then try to address them. No Issue then if you have programmed it properly in your code. Now your "myvec[1][1]" will become "myvec_1__1_" or "myvec_1_1" depending on how you want them to appear in your A2L file.
BTW: I have looked through the A2L (ASAP2) Standard and didn't find what you mentioned.
12-07-2017 09:57 AM
Hi again, I apologize for this late reply. I was told to postpone this issue due to more pressing concern.
Going back to what you wrote, it seems the problem is rather in the a2l file than in Labview.
First, I made a small mistake, there is no convention for the square brackets. It seems to be just the way some other programs (such as dspace controldesk) access the different components of an array.
I also looked again at the convention here:
https://wiki.asam.net/display/STANDARDS/ASAM+MCD-2+MC
This is what I have for a sample measurement array from my a2l:
/begin MEASUREMENT
/* Name */ MY_VARIABLE
/* LongIdentifier */ ""
/* Datatype */ FLOAT32_IEEE
/* Conversion */ CompuMethod_2
/* Resolution */ 1
/* Accuracy */ 0
/* LowerLimit */ -1E+17
/* UpperLimit */ 1E+17
ECU_ADDRESS 0x4000074C
MATRIX_DIM 2 1 1
/end MEASUREMENT
Again, if I try to access some of the properties listed above through labview (such as datatype or upperlimit), it works just fine. But it must be one of the properties both listed in the a2l and AVAILABLE in labview (and according to what I see, MATRIX_DIM is not among them).
Please correct me if I am wrong; what you are trying to suggest, is to “remove” the array definition in the a2l and “redirect” the array components as standalone measurements. So again, if I have an array called MYVEC with two components, I should create two different single measurements such as MYVEC_1_1 and MYVEC_2_1 instead of MYVEC with MATRIX_DIM.
Is it correct?
If it is so, we are moving to “read a measurement array” to “read a scalar measurement”. This is possible, but does not solve the original problem of reading a measurement array.
In addition, I receive the a2l from the software team and they said that they are not going to separate the arrays in single measurements.
12-07-2017 11:09 AM - edited 12-07-2017 11:19 AM
Typically, I have seen the arrays set as CHARACTERISTICS rather than MEASUREMENTS. For our purposes, we use arrays for holding strings. Earlier definition using NUMBER rather than DIM below:
/begin CHARACTERISTIC Version$ "" VAL_BLK 0x67F9C __UBYTE_Z 0 NO_FORMULA 0 255 EXTENDED_LIMITS 0 255 NUMBER 16 /begin IF_DATA ASAP1B_CCP KP_BLOB 0x1 0x67F9C 1 /end IF_DATA /begin IF_DATA CANAPE_EXT 100 LINK_MAP "Version" 0x0 0x1 0 0x67F9C 0 0x87 0x0 DISPLAY 0 0 255 /end IF_DATA /end CHARACTERISTIC
There are other options that I know of other than VAL_BLK [ASCII, CURVE, CUBOID, MAP, VALUE]. Furthermore, the usage of VAL_BLK is used for an array of values and might be able to handle your needs if defined properly.
BTW: The Wiki entry is fairly comprehensive; however, I looked through the ASAP2 released specification from March of 1994
06-06-2019 09:59 AM
This thread is a bit old by now, but did anyone ever find a solution?
I also have the need to read a measurement array/matrix/block with dimension 3x1. I do not have the ability and do not think it is a solution to modify the A2L to explicitly address the 3 values into individual measurements.
It does not seem even the 2018 ECUMC toolkit has this ability, when other HW/SW solutions such as Vector are able to do this.