Receive a CAN message, the identifier and contents of which are defined by a Vector CANdb file.
None (Main library). (See Section 2.3, “Licensed Features”.)
When a matching message to this block is received, the block unpacks the message contents into individual signals, as specified by the CANdb information, and provides them as outports in engineering units.
A CANdb file is a database of information regarding CAN nodes and CAN bus messages (more information regarding this format can be found by visiting the web site of Vector CANtech, Inc.). The database is edited using custom tools which make creation and maintenance of message information easier.
For each message, the database stores information like the message identifier, whether the identifier is standard or extended, what signals the message contains, etc.. For each signal, the database stores the start bit position, the bit length, bit ordering etc.. This block provides access to this information using the textual names assigned in the database, making the blocks easier to create and maintain (in contrast to the pcx_CANReceiveMessage block).
The block can provide a time stamp of when the message was received (see block mask parameter Provide Timestamp). The time stamp is a low accuracy time stamp, taken a short period of time after the message is received. That period of time is variable depending on the load of the processor and will therefore suffer jitter.
Warning
The PCX feature takes precedence over the PJ1939 feature. If you configure the PCX feature to receive a J1939 frame, the PJ1939 feature will not see the frame, and it will not be processed by the platform. This especially causes problems when receiving J1939 DM14 'Boot Load' commands.
A dummy input for simulation purposes only; may be grounded if not required. The value of outport error_flag in simulation.
Value type: Boolean Calibratable: No A dummy input for simulation purposes only; may be grounded if not required. The value of outport rx_trig_flag in simulation.
Value type: Boolean Calibratable: No A dummy input for simulation purposes only; may be grounded if not required. The value of outport overrun_flag in simulation.
Value type: Boolean Calibratable: No A dummy input for simulation purposes only; may be grounded if not required. The value of outport timestamp in simulation. Only available if the mask parameter Provide Timestamp is selected.
Value type: Integer A dummy input for simulation purposes only; may be grounded if not required. The value of outport checksum_err in simulation. Only available if the mask parameter Checksum Type is not None.
Value type: Boolean
Set to 1 if some error has occurred which prevents CAN reception, or 0 otherwise.
Type Conditions setting outport error_flag to 1 run time the size of the most recently received message differs from the one used in configuration configuration message not configured, because too many receive messages Value type: Boolean Calibratable: No Set to 1 if this message has been received at this iteration, or 0 otherwise. This flag will be set even if the received message length differs from the expected length.
Value type: Boolean Calibratable: No Set to 1 if more than one message with the same CAN message identifier has been received in one model iteration, or 0 otherwise. If more than one message has been received, the data from the latest message is used.
Value type: Boolean Calibratable: No A low accuracy time stamp of when the message was last received as indicated by rx_trig_flag, or zero if the message has never been received. The time stamp is a free running microsecond timer, which wraps to zero at its maximum (rather than saturating). Only available if the mask parameter Provide Timestamp is selected.
Value type: Integer Set TRUE if the most recently received message failed checksum validation or FALSE otherwise. Only available if the mask parameter Checksum Type is not None.
Value type: Boolean
The name of the CANdb file, including extension. A path may be included, either relative or absolute, however the directory containing the file must be on the MATLAB search path. If more than one file has a matching (partial) path and filename, precedence is given firstly to the current MATLAB directory and then to the first location on the MATLAB search path.
Only textual CANdb files are accepted (see restrictions in the notes section below).
Value type: String Calibratable: No The name of the message to receive. The name must be specified in the CANdb file and must match case (e.g., message name
EngineRPMis different from message nameenginerpm).Value type: String Calibratable: No A comma separated list of signal names to unpack from the message (e.g., "name1,name2" without the quotes). An empty list of names to unpack is supported, in which case the block shows no additional outports. This mode can be used to detect the presence of a message on the CAN bus without decoding any of the CAN message contents.
Value type: String Calibratable: No If selected then all signals from the message are created as outports (similarly simulation inports if required), if unselected then only those signals in the signal names field are created as outports.
If this field is ticked and the dialog closed, next time this field is unticked, the signal names field will contain the complete list of signals. This mechanism is useful when filling in the dialog for the first time but you are unsure of the field names (e.g., open block, fill in CANdb file name, message name, CAN bus and sample time, then tick this field, close the dialog, then select the block again, untick this field, then edit the list of required signals).
Value type: Boolean Calibratable: No If selected, a second set of outports are created for the message signals, each set to the raw integer value extracted from the CAN message prior to being scaled into engineering units.
The raw values are always reported as unsigned integers. If the CANdb signal is signed, then the application is responsible for conversion into a signed value. 32-bit signals may be converted by casting. Signals less than 32-bits must be sign extended to 32-bits prior to casting.
Value type: Boolean Calibratable: No Clip Signals To Engineering Limits?
If selected, each outport (except for the raw signal outports) is clipped to the limits for that signal defined by the CANdb file.
Value type: Boolean Calibratable: No If selected then each of the can message outport signals (and simulation inport signals) show their engineering units, if the CANdb file defines those units.
Value type: Boolean Calibratable: No Which can bus the message will be received on.
Value type: Integer Calibratable: No The periodicity of the block execution.
Range: [0.001, 3600] seconds
Value type: Real Calibratable: No If selected then inport sim_timestamp and outport timestamp are made available.
Value type: Boolean Calibratable: No A drop-down selection of the type of checksum to expect in the last raw message byte, computed over all of the preceding raw bytes in the message (even if they are not used by any signals). The default is None, and the other currently supported option is the 8-bit CRC defined by SAE-J1850. If used, the outport checksum_err is filled accordingly. In simulation, the value from inport sim_checksum_err is passed through.
Value type: List Calibratable: No If selected then dummy inputs for each of the outport can message signals, such as
sim_signal_name, are provided by the block.Value type: Boolean Calibratable: No
Unused signals in a CAN message need not be specified in the Signal Names parameter.
Not all OpenECU modules have both CAN buses populated (see Section 1.1, “ECU hardware reference documentation” for details about each device).
The signal data outports are updated any time a message is received as indicated by rx_trig_flag. If the error_flag outport is asserted due to a mismatch in message size, the data outports will contain potentially erroneous data from the incorrectly sized message. It is recommended that the application software latch the values of all CAN signals only when rx_trig_flag is set and error_flag is not set.
If the block does not show expected signals as outports, it is likely that one or more of the block fields is incorrect. Check the fields for mistakes and correct them.
Vector do not release the file format of CANdb files, so this block reads CANdb files as best it can. When reading the CANdb file, if it cannot understand the file format, the block will not show the request outports. Update the diagram to find out what the problem is.
If the block does not show the signal outports expected, there is probably a mistake in the CANdb file name or one of the signal names. Update the diagram to find out what the error is.
The CANdb blocks do not support extended signal multiplexing. If extended signal multiplexing is present in the CANdb file, then the block will not be able to interpret the file.
The CANdb blocks do not support signals defined in the CANdb file as signal type "double"
The CANdb blocks do not support CANdb messages without signals. For these messages, use the pcx_CANReceiveMessage block.
Due to the internal design of the CANdb blocks, a loss of precision may occur when dealing with integer values greater than 23 bits in size. This error increases as the value of the signal increases beyond this limit. If integer precision is required, it is recommended that the raw signal outports be used and for any scaling/offset specified in the DBC to be implemented by the application.