:Revision=7
:html
<<
128.170
KW2000-Object|KW2000
$NoSort
--
The IP-Object KW2000 accomplishes the 'Keyword Protocol 2000' according to ISO 14230. (Also known as K-Line, the L-Line is not provided)

New in Revision 5:

Hardware / protocols of the PortTypes
<h4>1. KLine via RS232</h4>
For the physical connection a serial interface is used with a K-Line converter (from MCD-Elektronik).
<h4>2. TP1.6 via CAN</h3>
CAN-Interface (z.B. CAN CardX)
<h4>3. TP2.0 via CAN</h4>
CAN-Interface (z.B. CAN CardX)
<h4>4. TP2.0 via MOST</h4>
Optolyzer build by OASIS on a serial interface

<!REM>
Remark:
Since now 2 <!RW>KW2000 interfaces are implemented, the bus number in the commands has to be 1 or 2.
<!TXT>
>>
<<
128.170.1
KW2000-Frame|Frame
--
A KeyWord 2000 frame consists of a header section (type byte, target- and sourceaddress and an optional length byte), the data bytes and the check sum.

The Keyword 2000 frames are saved byte by byte in a vector. Each element corresponds to a byte.

<h4>PortType KLine</h4>
There are two possibilities for the internal setup of the frame:

<ol indent=20>
<li>High-Level-access with <!RW>KW2000.Send and <!RW>KW2000.Received<br>In this mode only the data bytes are specified in the frame for the sending and the header of the frame is generated automatically according to the specification in the basic setup. During reception the header is removed and only the data bytes are returned. The check sum is generated automatically and removed.<br></li>
<li>Low-Level-access with <!RW>KW2000.Put and <!RW>KW2000.Get<br>In this mode only the check sum is generated and removed automatically. With <!RW>KW2000.Put the header and the data bytes must be specified whereby it is not checked whether the length specified in the header matches the length of the message; after the check sum is calculated and attached to the frame, the whole thing is sent out. During reception with <!RW>KW2000.Get the header is also returned too.<li>
</ol>

A mixed operation mode (e.g. send with <!RW>KW2000.Send and analyze with <!RW>KW2000.Get) is possible.

Messages in CARB-Mode are not received correctly. Messages with length specifications in format byte and extra length byte are received correctly. The check sum is checked with reception. 

<h4>other PortTypes (all TPx.x)</h4>
The interpreter will work only with the real data bytes, never with raw data. So, there is no difference between <!RW>Send and <!RW>Put resp. <!RW>Received and <!RW>Get. Any protocol handling is done indside the interpreter.
>>

<<
128.170.2
Functions of the KW2000-Object|Functions
--
>>
<<
128.170.2.1
KW2000.Received|Received
!128.170.2.7 - Get
--
<!DEF>
function <!TW>KW2000.Received (rNr : real) : vector;
<!TXT>
Returns the frame received with the last frame sent, whereby the header and the check sum are removed. If nothing is received the vector is empty. If the header is to be analyzed, then <!RW>Get can be used.

For any PortType except <!SW>KLine the command <!RW>Get is identical to <!RW>Received.
>>
<<
128.170.2.2
KW2000.IsActive|IsActive
--
<!DEF>
function <!TW>KW2000.IsActive : real;
<!TXT>
Returns <!RW>TRUE, if KW2000-Bus is activated globally

<!DEF>
function <!TW>KW2000.IsActive (rNr : real) : real;
<!TXT>
Returns <!RW>TRUE, if KW2000-Bus is activated globally and the KW2000-Bus <!PW>rNr is also active.
>>
<<
128.170.2.3
KW2000.IsOpen|IsOpen
--
<!DEF>
function <!TW>KW2000.IsOpen (rNr : real) : real;
<!TXT>
Returns <!RW>TRUE, if the KW2000-Bus <!PW>rNr is open.
>>
<<
128.170.2.4
KW2000.Check|Check
--
<!DEF>
function <!TW>KW2000.Check (vFrame, vTest : vector [; rMode : real]) : real;
<!TXT>
Compares the frame in the vector <!PW>vFrame with the frame in the vector <!PW>vTest.

 <!PW>vFrame may contain only values 0..255 (the bytes of the frame)
 <!PW>vTest may contain values in the range -1..255, -1=Don't care

 <!PW>rMode determines the behaviour in case of different lengths,
<!STBL>
<td>0<!>length must be identical (default)<!>
<!>1<!><!PW>vFrame may be shorter than vTest<!>
<!>2<!><!PW>vFrame may be longer than vTest, no test of the 'protruding' byte<!>
<!>3<!><!PW>vFrame may be longer or shorter<!>
<!ETBL>

Return: 0 = everything ok, otherwise the index of the position in <!PW>vFrame which differs.
>>
<<
128.170.2.5
KW2000.GetTiming|GetTiming
!128.170.3.5 - SetTiming
--
<!DEF>
function <!TW>KW2000.GetTiming (rNr, rItem : real) : real;
<!TXT>
Returns the timing of the KW2000-Bus <!PW>rNr. <!PW>rItem indicates which parameter must be read. Result in ms.

<!STBL>
<tr bgcolor=f0f0f0 align=center><td><b>rItem</b><!+>Parameter<!+>PortType<!+>Meaning<!>
<!c>1<!>Inter-Byte-Time P4/P5<!>KLine<!>Time between 2 sent bytes<!>
<!c>2<!>Timeout Receive P2<!>KLine<!>Timeout for recveiving<!>
<!c>3<!>Line Idle Time Min P3<!>KLine<!>Minimal time between answer and new request<!>
<!c>4<!>Line Idle Time Max P3<!>KLine<!>Maximal time between answer and new request<!>
<tr><td rowspan=2 align=center>5<!>Task Complete Timeout<!>all<!>Timeout for a complete request<!>
<tr><td colspan=3><!REM>Only used, when the negative response codes 21 resp. 78 are handled internally.<!TXT><!>
<tr><td rowspan=2 align=center>6<!>NRC21 Repeat Delay<!>all<!>Delay before new request after NRC 21<!>
<tr><td colspan=3><!REM>Only used, when the negative response code 21 is handled internally.<!TXT><!>
<!c>7<!>Timeout Ack<!>TP20 Most<!>Timeout while waiting for acknowledge (T1)<!>
<!c>8<!>Timeout Receive<!>TP20 Most<!>Timeout while receiving<!>
<!ETBL>
>>
<<
128.170.2.6
KW2000.Error|Error
!128.170.4 - ErrorCodes
--
<!DEF>
function <!TW>KW2000.Error (rNr : real) : real;
<!TXT>
Returns the result of the last action on the KW2000-Bus <!PW>rNr.
>>
<<
128.170.2.7
KW2000.Get|Get
!128.170.2.1
--
<!DEF>
function <!TW>KW2000.Get (rNr : real) : vector;
<!TXT>
Returns the frame received with the last frame sent. The frame contains the header. If nothing is received, then the vector is empty. If the header is not to be analyzed, then <!RW>Received can be used.

For any PortType except <!SW>KLine the command <!RW>Get is identical to <!RW>Received.
>>
<<
128.170.2.8
KW2000.Address.Get|Address.Get
--
<!DEF>
function <!TW>KW2000.Address.Get (rNr, rWhich : real) : real;
<!TXT>
Returns an address used in the KW2000 protocol on bus <!PW>rNr.

<!PW>rWhich selects the address:
<!STBL>
<!+>rWhich<!+>PortType<!+>Address<!>
<!c>1<!>KLine<!>ECU - address<!>
<!c>2<!>KLine<!>Tester - address<!>

<!c>3<!>TP20 Most<!>Tester address TP20<!>
<!c>4<!>TP20 Most<!>ECU address TP20<!>
<!c>5<!>TP20 Most<!>Receive ID CAN<!>
<!c>6<!>TP20 Most<!>Tester address MOST<!>
<!ETBL>

Any address can be read, but only those, matching the used port type will be used by the program.
>>
<<
128.170.2.9
KW2000.Mode.Get|Mode.Get
--
<!DEF>
function <!TW>KW2000.Mode.Get (rNr : real) : real;
<!TXT>
Returns the mode (PortType), of KW2000 port <!PW>rNr.

Return values:
<!STBL>
<!+>Value<!+>PortType<!>
<!c>0<!>KLine<!>
<!c>1<!>TP1.6 CAN<!>
<!c>2<!>TP2.0 CAN<!>
<!c>3<!>TP2.0 Most<!>
<!ETBL>
>>

<<
128.170.2.10
KW2000.Port.Get|Port.Get
--
<!DEF>
function <!TW>KW2000.Port.Get (rNr, rWhich : real) : string;
<!TXT>
Returns the name of the physical port, used by the KW2000 port for communication.

 <!PW>rWhich selects the port to be queried:

Values for <!PW>rWhich:
<!STBL>
<!+>Value<!+>Port<!>
<!c>1<!>TP1.6 CAN Port<!>
<!c>2<!>TP2.0 CAN Port<!>
<!ETBL>
>>

<<
128.170.3
Procedures of the KW2000-Object|Procedures
--
>>
<<
128.170.3.1
KW2000.Open|Open
--
<!DEF>
procedure <!TW>KW2000.Open (rNr : real);
<!TXT>
Opens the KW2000-Bus <!PW>rNr.
>>
<<
128.170.3.2
KW2000.Close|Close
--
<!DEF>
procedure <!TW>KW2000.Close (rNr : real);
<!TXT>
Closes the KW2000-Bus <!PW>rNr.
>>
<<
128.170.3.4
KW2000.Send|Send
!128.170.3.8 - Put
--
<!DEF>
procedure <!TW>KW2000.Send (rNr : real; .Frame : string|vector [; rTimeout : real [; rTaskTimeout : real [; var .Recv : string|vector]]]);
<!TXT>
Sends the frame in the vector <!PW>Frame on the KW2000-Bus <!PW>rNr and waites <!PW>rTimeout ms for the response. If <!PW>rTimeout is not specified, the basic setup value is used.

If the internal handlingof the Negative Response Code 21 / 78 is activated, then <!PW>rTimeout determines the time interval during which the DUT must send an answer. Then <!PW>rTaskTimeout determines how long the complete processing of the request may last. If <!PW>rTaskTimeout is not specified or -1, the basic setup value is used. If the internal error processing is not active, a <!PW>rTaskTimeout is not effective.

Instead of a vector a string can be specified. Then each character of the string is sent as a byte.

If the variable <!PW>Recv is given, the received answer will be returned in <!PW>Recv, as vector or string. This command combines <!RW>KW2000.Send and <!RW>KW2000.Received. 

Example:
<!CODE>
KW2000.Send (1, [$3E], -1, -1, vRecv);
// is equivalent to:
KW2000.Send (1, [$3E]);
vRecv:=KW2000.Receive (1);
<!TXT>

<!RW>Send is a High-Level-Routine which generates a header for the frame according to the basic setup. Therefore <!PW>Frame may contain only the data bytes. If a special, different header must be transferred, then <!RW>Put can be used.

For PortTypes other than <!SW>KLine the command <!RW>Put is identical with <!RW>Send.
>>
<<
128.170.3.5
KW2000.SetTiming|SetTiming
!128.170.2.5 - GetTiming
--
<!DEF>
procedure <!TW>KW2000.SetTiming (rNr, rItem, rTime : real);
<!TXT>
Modifies the Timing of the KW2000-Bus <!PW>rNr. <!PW>rItem indicates which parameter must be changed. <!PW>rTime indicates the new value (in ms).

<!STBL>
<tr bgcolor=f0f0f0 align=center><td><b>rItem</b><!+>Parameter<!+>PortType<!+>Meaning<!>
<!c>1<!>Inter-Byte-Time P4/P5<!>KLine<!>Time between 2 sent bytes<!>
<!c>2<!>Timeout Receive P2<!>KLine<!>Timeout for recveiving<!>
<!c>3<!>Line Idle Time Min P3<!>KLine<!>Minimal time between answer and new request<!>
<!c>4<!>Line Idle Time Max P3<!>KLine<!>Maximal time between answer and new request<!>
<tr><td rowspan=2 align=center>5<!>Task Complete Timeout<!>all<!>Timeout for a complete request<!>
<tr><td colspan=3><!REM>Only used, when the negative response codes 21 resp. 78 are handled internally.<!TXT><!>
<tr><td rowspan=2 align=center>6<!>NRC21 Repeat Delay<!>all<!>Delay before new request after NRC 21<!>
<tr><td colspan=3><!REM>Only used, when the negative response code 21 is handled internally.<!TXT><!>
<!c>7<!>Timeout Ack<!>TP20 Most<!>Timeout while waiting for acknowledge (T1)<!>
<!c>8<!>Timeout Receive<!>TP20 Most<!>Timeout while receiving<!>
<!ETBL>
>>
<<
128.170.3.6
KW2000.Wakeup|Wakeup
--
<!DEF>
procedure <!TW>KW2000.Wakeup (rNr, rMode : real; .Frame : string|vector [; rAddHead : real]);
<!TXT>
Executes a Wakeup on the KW2000-Bus <!PW>rNr.

 !PW>rMode indicates the type of Wake-Up; for the moment only 1 = Fast Wake up is allowed.
 Directly afterwards the frame is sent out and then the response is waited for the waiting period specified in the basic setup. 

If <!PW>rAddHead (default=<!RW>true) is <!RW>false, no header is calulated for the <!PW>Frame; otherwise (in default case) the header is generated according to the basic setup.

Instead of a vector a string can be specified as well. In this case each character of the string is sent as a byte.

The command <!RW>Wakeup has no function for PortTypes other than <!SW>KLine, since other PortTypes don't use a special WakeUp.
>>
<<
128.170.3.7
KW2000.KeepAlive|KeepAlive
--
<!DEF>
procedure <!TW>KW2000.KeepAlive (rNr : real; .Frame : string|vector [; rAddHead :real [; rIntervall : real]]);
<!TXT>
Defines the frame used for preserving the communication (time P3 max). If there is no communication for the period of P3 max, then the <!PW>Frame is sent.

If <!PW>rAddHead (default=<!RW>true) is <!RW>false, then no header is calculated for <!PW>Frame; otherwise (in default case) the header is generated according to the basic setup.

By specifying the <!PW>rIntervall a time which differs from the basic setup specification can be determined as P3 max (only in combination with the <!PW>rAddHead specification).

If <!PW>rIntervall=0 or if the <!PW>Frame is empty, then the monitoring of P3 max is switched off.

Instead of a vector a string can be specified as well. In this case each character of the string is sent as a byte.

For PortTypes other than <!SW>KLine the command <!RW>Put is identical with <!RW>Send.
>>
<<
128.170.3.8
KW2000.Put|Put
!128.170.3.4 - Send
--
<!DEF>
procedure <!TW>KW2000.Put (rNr : real; .Frame : string|vector [; rTimeout : real [; rTaskTimeout : real]]);
<!TXT>
Sends the frame in the vector <!PW>Frame on the KW2000-Bus <!PW>rNr and waits <!PW>rTimeout ms for the response. If <!PW>rTimeout is not specified or -1, then the basic value is used.

If the internal handling of the Negative Response Code 21 / 78 is activated, then <!PW>rTimeout determines the time interval during which the DUT must send an answer.

In this case <!PW>rTaskTimeout determines how long the complete processing of the request may last. If <!PW>rTaskTimeout is not specified or -1, the basic setup value is used.

If the internal error handling is not active, a <!PW>rTaskTimeout is not effective.

Instead of a vector a string can be specified as well. In this case each character of the string is sent as a byte.

<!RW>Put is a Low-Level-Routine where the header must be already in the frame. If the header must be generated automatically, then <!RW>Send must be used.

For PortTypes other than <!SW>KLine the command <!RW>Put is identical with <!RW>Send.
>>
<<
128.170.3.9
KW2000.Address.Set|Address.Set
--
<!DEF>
procedure <!TW>KW2000.Address.Set (rNr, rWhich, rAddress : real);
<!TXT>
Modifies the basic setup value of an address used on the Bus <!PW>rNr in KW2000 Protokol.

 <!PW>rWhich determines which address is changed:
<!STBL>
<!+>rWhich<!+>PortType<!+>changed address<!>
<!c>1<!>KLine<!>ECU - address<!>
<!c>2<!>KLine<!>Tester - address<!>
<!c>3<!>TP20 Most<!>Tester address TP20<!>
<!c>4<!>TP20 Most<!>ECU address TP20<!>
<!c>5<!>TP20 Most<!>Receive ID CAN<!>
<!c>6<!>TP20 Most<!>Tester address MOST<!>
<!ETBL>

 <!PW>rAddress is the address that is going to be used in the future (0..255)

Any address can be read, but only those, matching the used port type will be used by the program.

>>
<<
128.170.3.10
KW2000.Tunnel|Tunnel
--
<!DEF>
procedure <!TW>KW2000.Tunnel (rNr : real; sData : string [; rWait : real [; var sRecv : string]]);
<!TXT>
Will send the data in <!PW>sData on the KW2000 bus <!PW>rNr in a kind of protocol tunnel, directly to the base media, without doing protocol conversions. <!PW>sData is not interpreted as <!SW>KW2000 command.

If <!PW>rWait and <!PW>sRecv are not given, the interpreter will not wait for the sending of the data.

 <!PW>rWait selects, when the call returns:
<!STBL>
<!+>rWait<!+>Function<!>
<!c>0<!>Transfers the data to the protocol layer and returns immediately. <!PW>sRecv is not used.<!>
<!c>1<!>Transfers the data to the protocol layer and waits until they are sent. <!PW>sRecv is not used.<!>
<!c>2<!>Transfers the data to the protocol layer and returns when an answer has been received. <!PW>sRecv has to be given and will hold the answer after the call.<!>
<!ETBL>

Tunneling is not supported/needed in all PortTypes:
<h4>KLine</h4>
Not supported. Data can be send directly with <!RW>RS232 calls.
<h4>TP1.6_CAN</h4>
Not supported. CAN-Frames can be send directly with <!RW>CAN commands. It is nevertheless not allowed to send CAN frames with IDs used by KW2000 diagnosis.
<h4>TP2.0_CAN</h4>
not implemented yet
<h4>TP2.0_MOST</h4>
Will send <!PW>sData directly to the serial interface. <!PW>sData has to be a valid MOST command formatted in the Optolyzer for MOST protocol. Tunneling is necessary, since the data on the serial port is read by the KW2000 Thread. The KW2000 protocol handling would be confused by unexpected MOSt frames.

>>
<<
128.170.3.11
KW2000.Mode.Set|Mode.Set
--
<!DEF>
procedure <!TW>KW2000.Mode.Set (rNr, rMode : real);
<!TXT>
Set the mode (PortType) of the KW2000 port <!PW>rNr.

Values for <!PW>rMode:
<!STBL>
<!+>Value<!+>PortType<!>
<!c>0<!>KLine<!>
<!c>1<!>TP1.6 CAN<!>
<!c>2<!>TP2.0 CAN<!>
<!c>3<!>TP2.0 Most<!>
<!ETBL>
>>
<<
128.170.3.12
KW2000.Port.Set|Port.Set
--
<!DEF>
procedure <!TW>KW2000.Port.Set (rNr, rWhich : real; sPort : string);
<!TXT>
Assigns a physical port to be used by the K2000 port.
This is only working for TP X.X CAN port types.

 <!PW>rWhich selects the port to be configured:

Values for <!PW>rWhich:
<!STBL>
<!+>Value<!+>Port<!>
<!c>1<!>defined the TP1.6 CAN port<!>
<!c>2<!>define the TP2.0 CAN Port<!>
<!ETBL>
The assignment will be used, when the port is opened the next time and is not stored permanently - with the next program reset, the values from basic setup will be used again.
>>
<<
128.170.4
Error codes of the KW2000-Object|Error codes
!128.170.2.6 - Error
--
The errocodes differ with the PortType

<ul indent=15>
<li><a href="128.170.4.1">Error codes for PortType <b>KLine</b></a><p></p></li>
<li><a href="128.170.4.4">Error codes for all <b>TPx.x</b> PortTypes</a></li>
</ul>
>>
<<
128.170.4.1
Error codes of the KW2000-Object, PortType KLine|KLine error codes
!128.170.2.6 - Error
--
<!STBL>
<!+>Code<!+>Meaning<!>
<!c>0<!>OK<!>
<!c>1<!>Serial port not available<!>
<!c>2<!>Port cannot be opened<!>
<!c>3<!>Port not opened<!>
<!c>4<!>Timeout<!>
<!c>5<!>Check sum is wrong<!>
<!c>6<!>reading error (K-Line-Converter OK?)<!>
<!c>7<!>Frame is incorrect<!>
<!ETBL>
>>
<<
128.170.4.4
Error codes of the KW2000-Object, PortType TPx.x|TPx.x error codes
!128.170.2.6 - Error
--
<!STBL>
<!+>Code<!+>Meaning<!>
<!c>0<!>OK - no error<!>
<!c>1<!>ChannelSetup No Answer<!>
<!c>2<!>ChannelSetup Answer Not For Tester<!>
<!c>3<!>ChannelSetup Application Incorrect<!>
<!c>4<!>ChannelSetup TXID Mismatch<!>
<!c>5<!>ChannelSetup Info RX Incorrect<!>
<!c>6<!>ChannelSetup Application Not Supported<!>
<!c>7<!>ChannelSetup Application Temporary Not Supported<!>
<!c>8<!>ChannelSetup Temporary No Resources<!>
<!c>9<!>ChannelSetup Unexpected Answer<!>
<!c>10<!>ChannelSetup Port Was Closed<!>
<!c>11<!>ConnectionSetup Channel Not Open<!>
<!c>12<!>ConnectionSetup Not Acknowledged<!>
<!c>13<!>ConnectionSetup No Answer<!>
<!c>14<!>Disconnect Port Was Closed<!>
<!c>15<!>Not Connected<!>
<!c>16<!>Invalid Transmit Frame Length<!>
<!c>17<!>No Acknowledge For Telegram<!>
<!c>18<!>Got A Break<!>
<!c>19<!>Timeout In Thread Receive<!>
<!c>20<!>Invalid Receive Frame Length Field<!>
<!c>21<!>Timeout In NRC78 Handling<!>
<!c>22<!>ChannelSetup Negative Reply<!>
<!c>23<!>ConnectionSetup KLine Not Open<!>
<!c>24<!>Function not supported<!>
<!ETBL>
>>
<<
128.170.5
Negative Response Codes
--
Listing of the Negative Response Codes defined in ISO14230 
(the xx in the frames are of the &quot;Fmt Tgt Src 7F SID xx&quot; type)

Quotes according to the specification. The term &quot;client (tester)&quot; and / or &quot;server (ECU)&quot; is always replaced by &quot;tester&quot; and / or &quot;ECU&quot; 
ECU = Electronic Control Unit -> the DUT

<!STBL>
<tr><td rowspan=2 valign=top><b>$10</b><!><b>GeneralReject - GR</b><!>
<!>The service is rejected but the ECU does not specify the reason of the rejection.<!>
<tr><td rowspan=2 valign=top><b>$11</b><!><b>ServiceNotSupported - SNS</b><!>
<!>This response code indicates the requested action will not be taken because the ECU dose not support the requested service.<!>
<tr><td rowspan=2 valign=top><b>$12</b><!><b>SubFunctionNotSupported-Invalid Format - SFNS-IF</b><!>
<!>This response code indicates that the requested action will not be taken because the ECU does not support the arguments of the request message or the format of the argument bytes do not match the prescribed format for the specified service.<!>
<tr><td rowspan=2 valign=top><b>$21</b><!><b>Busy->RepeatRequest - B-RR</b><!>
<!>This response code indicates that the ECU is temporarily too busy to perform the requested operation. In this circumstance repetition of the &quot;identical request message&quot; or &quot;another request message&quot; shall be performed by the tester . This response code shall be returned for example while a ECU is in the process of clearing stored DTCs information or fetching information.<br>
<b>This NRC can be handled internally by the KW2000-Module</b><!>
<tr><td rowspan=2 valign=top><b>$22</b><!><b>ConditionsNotCorrectOrSequestSequenceError - CNCORSE</b><!>
<!>This response code indicates that the requested action will not be taken because the ECU prerequisite conditions are not met. This request may occur when sequence sensitive requests are issued in the wrong order.<!>
<tr><td rowspan=2 valign=top><b>$23</b><!><b>RoutineNotComplete - RNC</b><!>
<!>This response code indicates that the request message was properly received by the ECU and the routine, which has been initiated by the request message is already in process, but not yet completed. The ECU knows in advance that the processing time is greater than the P2 timing window. The successful execution and completion of the request message will not be indicated by a positive response message. In case the tester repeats the request message the ECU shall &quot;not reinitiate the task&quot; if the initial task has not been completed.<br>
<b>This NRC can be handled internally by the KW2000-Module</b><!>
<tr><td rowspan=2 valign=top><b>$31</b><!><b>RequestOutOfRange - ROR</b><!>
<!>This response code indicates that the requested action will not be taken because the ECU detects the request message contains a data byte which attempts to substitute a value beyond its range of authority. (e.g. attempting to substitute a data byte of 111 when the data is only defined to 100).<!>
<tr><td rowspan=2 valign=top><b>$33</b><!><b>SecurityAccessDenied-securityAccessRecuested - SAD-SAR</b><!>
<!>This response code indicates that the requested action will not be taken because the ECU's security strategy has not been satisfied by the tester.<!>
<tr><td rowspan=2 valign=top><b>$35</b><!><b>InvalidKey - IK</b><!>
<!>This response code indicates that security access has not been given by the ECU because the key send by the tester did not match with the key in the ECU's memory. This counts as an attempt to gain security. The ECU shall remain locked!<!>
<tr><td rowspan=2 valign=top><b>$36</b><!><b>ExceedNumberOfAttempts - ENOA</b><!>
<!>This response code indicates that the requested action will not be taken because the tester has unsuccessfully attempted to gain security access more times than the ECU's security strategy will allow.<!>
<tr><td rowspan=2 valign=top><b>$37</b><!><b>RequiredTimeDelyNotExpried - RTDNE</b><!>
<!>This response code indicates that security access has not been taken by the ECU because the tester sent a false key two or more than two times. After two or more than two times sending a false key to ECU, the ECU automatically inserts a 10s delay time. If the tester tries to execute the SecurityAccess in the 10s interval, the ECU will refuse the attempt and sends back this response.<!>
<tr><td rowspan=2 valign=top><b>$41</b><!><b>ImproperDownloadType - IDT</b><!>
<!>This response code indicates that an attempt to download to a ECU's memory cannot be accomplished because the ECU does not support the type of download being attempted.<!>
<tr><td rowspan=2 valign=top><b>$42</b><!><b>CanNotDownloadToSpecifiedAddress - CNDTSA</b><!>
<!>This response code indicates that an attempt to download to a ECU's memory cannot be accomplished because the ECU does not recognize the target address for the download as being available.<!>
<tr><td rowspan=2 valign=top><b>$43</b><!><b>CanNotDownloadNumberOfBytesRequested - CNDNOBR</b><!>
<!>This response code indicates that an attempt to download to a ECU's memory cannot be accomplished because the ECU does not recognize the number of bytes for the download as being available.<!>
<tr><td rowspan=2 valign=top><b>$64</b><!><b>AbnormalExitWihtoutResult</b><!>
<!>This response code indicates that there was a ECU hardware fault. The ECU may be defect and there are no valid results available .<!>
<tr><td rowspan=2 valign=top><b>$78</b><!><b>RequestCorrectlyReceived-ResponsePending - RCR-RP</b><!>
<!>This response code indicates that the request message was received correctly, and that any parameters in the request message were valid, but the action to be performed may not be completed yet. This response code can be used to indicate that the request message was properly received and does not need to be re-transmitted, but the ECU is not yet ready to receive another request.
This response code shall only be used in a negative response message if the ECU will not be able to receive further request messages from the tester within the P3 timing window. This may be the case if the ECU does data processing or executes  a routine which does not allow any attention to serial communication.
The following description specifies the communication timing method: This response code shall manipulate the P2max timing parameter value in the ECU and the tester. The P2max timing parameter is set to the value [in ms] of the P3max timing parameter. In addition, the tester shall disable the TesterPresent service. As soon as the ECU has completed the task (routine) initiated by the request message it shall send either a positive or negative response message (negative response message with a response code other than $78) based on the last request message received.
When the tester has received the positive response message which has been preceded by the negative response message(s) with this response code the tester and the ECU shall reset the P2timing parameter to the previous P2 timing
value. In addition the tester shall re-enable the TesterPresent service. The tester shall not repeat the requested message after the reception of a negative response message with this response code!
<b>This NRC can be handled internally by the KW2000-Module</b><!>
<tr><td rowspan=2 valign=top><b>$80</b><!><b>ServiceNotSupportedInActiveDiagnosticMode - SNSIADM</b><!>
<!><!REM>No information available<!TXT><!>
<tr><td rowspan=2 valign=top><b>$90</b><!><b>MessageFrameOverflow - MFO</b><!>
<!>If the ECU has to transmit more bytes than one massage-frame is able to carry, the ECU has to transmit this Response-Code within the negative response-message.<!>
<tr><td rowspan=2 valign=top><b>$91</b><!><b>ServiceNotSupportedSecurityConditionsNotCorrect - SNSSCNC</b><!>
<!>This response code indicates that the requested service will cause a dangerous vehicle-situation and has to be rejected in this diagnostic mode (session).<!>
<tr><td rowspan=2 valign=top><b>$92</b><!><b>AccessDeniedBecauseVehicleMoves - ADBVM</b><!>
<!>This response code indicates that the requested service will cause a dangerous vehicle-situation, because the vehicle moves. Therefore the service has to be rejected in this diagnostic mode(session).<!>
<tr><td rowspan=2 valign=top><b>$FA</b><!><b>ChecksumError - CSERR</b><!>
<!>This response code indicates an application-RAM or flash-EEPROM checksum error.<br>
Example: if the local routine &quot;compareChecksum&quot; results in a checksumerror, upon the RequestRoutineResultsBxLID message the ECU will send a negative response including the response code &quot;checksumError&quot;<!>
<tr><td rowspan=2 valign=top><b>$FB</b><!><b>ECUErasingFlash - ERASE</b><!>
<!>This response code indicates that the ECU is currently erasing the flash-EPROM. During this period, all received request messages (except testerPresent, stopCommunication and ecuReset) have to be rejected with this response code.<!>
<tr><td rowspan=2 valign=top><b>$FC</b><!><b>ECUProgrammingFlash - PROG</b><!>
<!>This code indicates that ECU is currently programming the flash-EPROM.<!>
<tr><td rowspan=2 valign=top><b>$FD</b><!><b>ErasingError - ERERR</b><!>
<!>This response code indicates a fault during erasing the flash-EPROM.<!>
<tr><td rowspan=2 valign=top><b>$FE</b><!><b>ProgrammingError - PRERR</b><!>
<!>This response code indicates a fault during programming the flash-EPROM.<!>
<!ETBL>
>>

