This chapter will break down the usage of the SCFE.
After reading this article, you should have the knowledge:
The SCFE dialog is used to select signals and parameters from a bus database file and map them to the created pins for the
So it is possible to configure the Encoder or Decoder Filter with the signals and parameters you need. For example you want to decode the velocity value of your car (which is measured by your connected engine control unit). So you have to select the velocity signal from loaded bus database(s) and create a output pin with this signal.
You have to open the context menu of the En-/Decode-Filter and choose :
The dialog like the one you can see below will be displayed:
If you have set the MapFilename property of the En-/Decode-Filter, the SCFE load the configuration file and show the configured pins within the Configuration view. Otherwise you will get an empty configuration.
To create a new map file for your filter, go into the SCFE and:
Within the Configuration view you can add pins to your configuration by open the context menu and clicking or :
|channel||tInt32||The channel on which the referenced messages and signals are available.|
|channelmask||cString||Through the channel mask a range of possible channels can be specified. Each bit in this 32bit integer corresponds to a channel number.|
|cycletime||tInt32||Cyclic transmission of the buffer. Default -1.|
|delay||tInt32||A fixed delay that will be substracted from the buffer timestamp.|
|pack||tInt32||Memory packing in the buffer. The default is 8.|
|timestamp||cString||Specifies when and how the time stamp is set for the decoded data: $FIRST$: time stamp of the first valid message in the cycle for this buffer $LAST$: time stamp of the last message in the cycle before the data of this buffer is sent. $MEAN$: average value of the $FIRST$ and $LAST$ time stamp MessageName: time stamp of the corresponding message is used if this is received (otherwise 0)|
After naming and configuring the pin you can drag and drop one or more signals from the Databases view to your new pin.
So the configuration could look like this:
Like before, you have to configure your used signals/parameters via the Properties view:
|bits||tInt32||Signal bit length|
|corrective_factor||tFloat64||Additional computation factor|
|corrective_offset||tFloat64||Additional computation offset|
|default_value||tFloat64||Default value from database or configuration file|
|limits||cString||Can be used to override the property setting for global limit handling|
|macro||cString||Name of a macro that should be executed to fill the structure element
Note: Currently property has no effect, but will be enabled in one of the next releases.
|name||cString||Name of the structure element|
|sign_signal||cString||Reference a seperate sign signal|
|signal||cString||The exact notation of the SignalName as in the corresponding database file|
|type||cString||Data type of the structure element|
|unit_conversion||cString||For read-in "unit_conversion"|
|value||cString||Set constant signal value|
|channel||[0..16]||No, either channel or channelmask must be defined.||The channel on which the referenced messages and signals are available.|
|channelmask||hexadecimal||No, either channel or channelmask must be defined.||Through the channel mask a range of possible channels can be specified. Each bit in this 32bit integer corresponds to a channel number.|
|delay||milliseconds||yes||A fixed delay that will be substracted from the buffer timestamp.|
|pack||1,2,4,8,16||yes||Memory packing in the buffer. The default is 8.|
|yes||Specifies when and how the time stamp is set for the decoded data: $FIRST$: time stamp of the first valid message in the cycle for this buffer $LAST$: time stamp of the last message in the cycle before the data of this buffer is sent. $MEAN$: average value of the $FIRST$ and $LAST$ time stamp MessageName: time stamp of the corresponding message is used if this is received (otherwise 0)|
|clear_after_transmit||bool||yes||Clear the buffer to 0 after transmitting.|
|cycletime||milliseconds||InputPin Only||Cyclic transmission of the buffer. Default -1.|
|pack||1,2,4,8,16||yes||Memory packing in the buffer. The default is 8.|
|array_index_name||string||yes||A name that can be used to a placeholder for the array index in the elemnts’ signal name (MessageName.Signal$array_index_name$).|
|array_start_index||integer||yes||Start index of the array.|
|array_stop_index||integer||yes||End index of the array.|
|array_format||format specifier||yes||printf format specifier for the array index.|
The struct node defines a specific C-structure, whose elements can be filled with decoded signals, macros
or just nothing. A buffer node can contain multiple structs with different attributes (array, pack, etc.). When
creating the structures, special care must be taken that the "pack" specification
#pragma pack (see Microsoft Visual Studio help) of the C-structure so that the alignment of the individual structure
elements fits! By default in Visual Studio, a
#pragma pack(8) is set.
doublevalue. GCC uses a 4 byte alignment for all 64 bit types. For
#pragma pack-values larger than 1, this can lead to a different memory layout of the structure!
|type||ADTF data type||no||Data type of the structure element. Valid types: tBool, tInt8, tUInt8, tInt16, tUInt16, tInt32, tUInt32, tInt64, tUInt64, tInt, tUInt, tFloat64, tFloat32|
|signal||Message.Signal||yes, when macro is used||"MessageName.SignalName" in the exact notation as in the corresponding database file.|
|corrective_factor||float||yes||Factor to apply to the signal before the buffer is transmitted.|
|corrective_offset||float||yes||Offset to apply to the signal before the buffer is transmitted.|
|unit_conversion||bool||yes||Apply the unit conversion described in the database file.|
|sign_signal||SignalName||yes||Reference a separate sign signal.|
|yes||Select a limit handling policy. With this you can clip a signal to the min/max values specified in the database file or warn via log message when the limits are exceeded.|
|timeout||milliseconds||yes||Triggers the buffer after the specified time (depends on the Stream Time) if the required signals have not been received entirely. If all signals were received before the timeout, the buffer is transmitted and the timeout will reset.|
|start_msg||MessageName||yes||The name of the message that triggers a new decoding cycle. All other received messages which are configured in the buffer will be ignored until this message was received. It is possible to use only the message as trigger (without valid checking see below). The start message has to be received at the same channel as configured in the buffer.|
|start_valid_signal||SignalName||yes||Used in combination with start_msg to select a signal in the message that is used as a source for a value comparison.|
|start_valid_value||NumericValue||yes||The value which the start_valid_signal will be compared against.|
|start_valid_operation||[==,!=,>=,<=,>,<]||yes||The operation used in the comparison.|
|stop_msg||MessageName||yes||The name of the message that stops the current decoding cycle. After receiving the message, a new sample will be transmitted. If there is configured a start_msg, all other received messages which are configured in the buffer will be ignored until the start_msg was received. It is possible to use only the message as trigger (without valid checking see below). The stop message has to be received at the same channel as configured in the buffer. The value should have the following structure: ECUName.PDUChannelValue.PDUName|
|stop_valid_signal||SignalName||yes||Used in combination with stop_msg to select a signal in the message that is used as a source for a value comparison.|
|stop_valid_value||NumericValue||yes||The value which the stop_valid_signal will be compared against.|
|stop_valid_operation||[==,!=,>=,<=,>,<]||yes||The operation used in the comparison.|
The optional trigger specifies when a decoding cycle begins and when it ends. If no such node exists, all appropriate messages are decoded and, if all messages required for the buffer were received, the sample is sent. During this step multiplexed signals are treated just as signals from different messages, i.e. all needed multiplexes of a message must have been received to trigger a transmit. By setting the stop_valid_signal to the multiplexor it is possible to trigger the buffer transmission on specific multiplexes. The stop trigger can be composed of a stop message (with an optional valid condition) and a timeout.
We would like to roundup the article by explaining further SCFE functionalities.
With the help of the - menu, configuration and database files are handled. The following menu points are available:
The - menu offers additional operations that can be executed. The following menu entries are available: