From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Automotive and Embedded Networks
CAN database scaling, units and additional information
Solved!
Lots of great questions, you are on the right track.
1. I know that in the dbc-File signals have a scaling factor plus offset and a unit. Does the signal values considered scaling factor and offset (if not then I have to calculate by myself)?
When you perform a read or write on the signal, this will be in engineering units. Meaning if you read something like "Engine Speed" it will be in the units you mentioned which in this case is likely RPM. No need to apply any scale XNet does that based on the DBC. Similarly the scale is applied when you write a value. If you are writing "Engine Speed" perhaps in simulating the engine running you'd write the value in that same units of RPM. You don't need to apply any scale when using the signal, XNet already does that for you.
@HH_20182. If I read a scaled signal value, can I read the unit of this signal only per property node?
Yes the units on a signal can be read using the property node. This obviously won't change unless you change the DBC, so you can probably read this once at the start of your application and keep them around if you need them later for display or logging purposes.
@HH_20183. I see additional information for a signal in the database file, e.g. a contactor has different states (3 "Not available" 2 "Error" 1 "Connected" 0 "Not connected") Are this additional information readable via Vi or property node?
This can be read with the subVI Get DBC Attribute found here. Have the mode as Signal Value Table, and it will return the values, and their string representations.
@HH_20184. For me it is not clear how a single signal can be send in a frame with more signals. Does the other signals on the same frame will be set to zero or will they keep their values?
Sorry for the basic questions, I am starting new in XNET and CANdb programming.
This is true. When a single CAN frame goes out, all signals in that frame will be sent. That payload will contain between 0 and 64 signals and you can't send one signal without sending all of them. If you only write values for say Voltage1 and Voltage2 is also in that frame, then the value for Voltage2 will be the Default value, as defined in the DBC. This can be read with property nodes, and is seen in the database editor, under that signal. Some times this default value is an invalid value, so that other devices see this and know it hasn't been set yet.
Sounds like you know a decent amount already but I do have a 10 part blog series on LabVIEW and CAN with a couple posts dedicated to XNet, but I admit that my posts probably wouldn't have answered all of your questions.
But writing a signal with “Signal output single point” can be a problem if I have to write different values on different signals of the same frame during testing the ECU.
Then it might be better to write a complete frame with “Frame output single point” to have a better control over all signals of the frame (no need to take care about the “Default values”). In this case I have to calculate the scaling and offset by myself. Is this correct?
You can choose to go with the Frame Single Point if you choose. This of course will mean you need to either do the conversion yourself, or use a conversion session to see what that frame will look like with those values.
But honestly this is work you don't need to do. You use the Signal Single Point, and just write all of your signals at once, then when there are new values to write update them all. This list of signals can be from all the frames you want giving them all the values you want. And when the next frame goes out it should have the values you tried writing for that frame. Having the frame signal conversion happening on the hardware is another benefit over trying to do the conversion in software.
Attached is a quick example of what I mean. This will write 3 signals to a CAN interface. Two of the signals are in one frame, and 1 is from another. The second frame also has another signal in it that isn't being written which will default to 0. Run the VI then select one of the three signals from the list box. The value should load into Value. Change the value in Value and it will write that along with all the other values back. Notice that the write will write all signals at once, so when the frame goes out it will contain all the signal values.
2012 attached. To be fair there is a "CAN Signal Output Single Point" example in the Help >> Find Examples. It more or less is what I wrote but I prefer the event driven code I made, although it won't work on RT. NI's example also reads signal defaults and starts with those values which is a good idea.
