DEEP SEA ELECTRONICS

DSE CAN Functions Library

Document Number: 057-336

Author: Anthony Manton

057-336 ISSUE: 1.6.3

 DSE CAN Functions Library

Deep Sea Electronics Ltd

Highfield House
Hunmanby
North Yorkshire
YO14 0PH
ENGLAND

Sales Tel: +44 (0) 1723 890099

Sales Fax: +44 (0) 1723 893303

E-mail: sales@deepseaelectronics.com
Website: www.deepseaelectronics.com

DSE CAN Functions Library

© Deep Sea Electronics Ltd

All rights reserved. No part of this publication may be reproduced in any material form (including
photocopying or storing in any medium by electronic means or other) without the written permission of
the copyright holder except in accordance with the provisions of the Copyright, Designs and Patents
Act 1988.
Applications for the copyright holder’s written permission to reproduce any part of this publication
must be addressed to Deep Sea Electronics at the address above.

The DSE logo and the name DSEControl® are UK registered trademarks of Deep Sea Electronics Ltd.

Any reference to trademarked product names used within this publication is owned by their respective
companies.

Deep Sea Electronics reserves the right to change the contents of this document without prior notice.

057-336 ISSUE: 1.6.3 Page 2 of 48

 DSE CAN Functions Library

Document Revision History

This document issue number is in the form x.y.z

x.y refers to the version of DSE CAN Functions Library that is documented (along with previous
versions).
Change in the z portion, refer to changes in the documentation only.

Issue No. Comments

1.6.0 Initial release of document covering DSE CAN Functions Library V1.0 to V1.6
1.6.1 Added more detail in Section 3.3.2 De-initialise.
1.6.2 Added Example 2 to Build J1939_BuildTSC1
1.6.3 Added Little Endian section to show methods of converting Bytes in the CAN message into 16
bit and 32 bit values.

DSE CAN Functions Library Change Notes

Issue No. Comments

1.0 Initial release of DSE CAN Functions Library
1.1 Added enums for eCANList and eBaudrate
1.2 Addition of NewMessage output from CANReceive
1.3 Improvements to CANDiagnosis
1.4 Addition of CANReceiveSingle
1.5 Improved recovery from external CAN bus errors
1.6 Addition of CANReceiveMask and J1939 folder tree and associated functions

Page 3 of 48 057-336 ISSUE: 1.6.3

 DSE CAN Functions Library

TABLE OF CONTENTS
Section Page
1 INTRODUCTION .................................................................................................. 6
1.1 CLARIFICATION OF NOTATION ............................................................................................ 6
1.2 GLOSSARY OF TERMS .......................................................................................................... 7
1.3 RELATED INFORMATION ...................................................................................................... 8
1.3.1 SAMPLE PROJECT FILES ............................................................................................... 8
1.3.2 TECHNICAL INFORMATION ............................................................................................ 9
1.4 LIBRARY COMPATIBILITY AND VERSION NUMBERING ................................................. 10
1.5 SAFETY INSTRUCTIONS ..................................................................................................... 11
1.5.1 GENERAL ....................................................................................................................... 11
2 INSTALLATION ................................................................................................. 12
2.1 DSE_UTILS ............................................................................................................................ 12
3 LIBRARY USAGE.............................................................................................. 13
3.1 ADD TO LIBRARY MANAGER ............................................................................................. 13
3.2 DSE CAN FUNCTIONS LIBRARY ONLINE HELP ............................................................... 15
3.3 INITIALISE / DEINITIALISE THE CAN PORT(S) .................................................................. 16
3.3.1 INITIALISE....................................................................................................................... 16
3.3.2 DE-INITIALISE ................................................................................................................ 16
3.4 CAN RAW .............................................................................................................................. 17
3.4.1 RECEIVING MESSAGES ............................................................................................... 18
3.4.1.1 CANRECEIVE .......................................................................................................... 19
3.4.1.2 CANRECEIVEMASK ................................................................................................ 19
3.4.1.3 CANRECEIVESINGLE............................................................................................. 20
3.4.2 TRANSMITTING MESSAGES ........................................................................................ 21
3.4.2.1 CANTRANSMIT ....................................................................................................... 21
3.4.3 ADDING A WATCHDOG TO CAN RAW ........................................................................ 22
3.5 CAN J1939 ............................................................................................................................. 23
3.5.1 RECEIVING MESSAGES ............................................................................................... 23
3.5.1.1 J1939_RECEIVE ...................................................................................................... 24
3.5.1.2 READ_XXXX ............................................................................................................ 25
3.5.1.3 J1939_DM1_DM2 .................................................................................................... 27
3.5.2 TRANSMITTING MESSAGES ........................................................................................ 29
3.5.2.1 J1939_TRANSMIT ................................................................................................... 29
3.5.2.2 J1939_REQUEST .................................................................................................... 30
3.5.3 ADDING A WATCHDOG TO CAN J1939 ....................................................................... 31
3.5.4 HELPER FUNCTIONS .................................................................................................... 32
3.5.4.1 SLOT ........................................................................................................................ 32
3.5.4.2 J1939_DTCSCROLLER ........................................................................................... 33
3.5.4.3 J1939_DTCSCROLLER FUNCTION PARAMETERS ............................................. 34
3.5.4.4 J1939_BUILDTSC1 .................................................................................................. 35
3.6 CANDIAGNOSIS .................................................................................................................... 37
3.6.1 BUSSTATE...................................................................................................................... 38
3.6.1.1 DSEM640 & DSEM643 ............................................................................................ 38
3.6.1.2 DSEM840 ................................................................................................................. 39
3.6.1.3 DSEM870 & DSEM812 ............................................................................................ 39
4 LIBRARY APPLICATIONS ................................................................................ 40
4.1 DATA TRANSMISSION ......................................................................................................... 40
4.1.1 J1939 ............................................................................................................................... 40
4.1.2 CAN RAW........................................................................................................................ 40
4.1.3 REAL VALUES ................................................................................................................ 41
4.1.3.1 ADVANCED ............................................................................................................. 41
4.1.4 BOOL ............................................................................................................................... 42
4.1.5 STRING ........................................................................................................................... 42
4.2 LITTLE ENDIAN? ................................................................................................................... 43
4.2.1 DSE_UTILS ..................................................................................................................... 44

057-336 ISSUE: 1.6.3 Page 4 of 48

 DSE CAN Functions Library

4.2.2 BIT SHIFTING / MULTIPLICATION ................................................................................ 44

5 TROUBLESHOOTING ....................................................................................... 45

Page 5 of 48 057-336 ISSUE: 1.6.3

 Introduction

1 INTRODUCTION
This document details the CODESYS DSE CAN Functions Library. This provides CODESYS
functions to aid the use of the CAN port integrated with DSEControl® CODESYS range of products.
This document is not intended to detail the specification of CAN or associated protocols and
knowledge of these is assumed.
Prior knowledge of CODESYS and DSEMSeries devices is assumed.

Functions are provided to allow the DSE MSeries device to operate as a fully functional CAN Node
with both transmission and reception functions. Helper functions are also available to provide high-
level J1939 functionality such as reception of DM1 and DM2 (diagnostic messages) and transmission
of TSC1 (torque and speed control) messages.

The manual forms part of the product and should be kept for the entire life of the product. If the
product is passed or supplied to another party, ensure that this document is passed to them for
reference purposes.
This is not a controlled document. DSE do not automatically inform on updates. Any future updates of
this document are included on the DSE website at www.deepseaelectronics.com

These instructions and examples are for authorised persons and intended as a guide to using the
library. They do not form a complete application. The device must be programmed, tested, installed,
connected, and put into operation by qualified Engineers.

1.1 CLARIFICATION OF NOTATION

Clarification of notation used within this publication.

Highlights an essential element of a procedure to ensure correctness.

NOTE:

Indicates a procedure or practice, which, if not strictly observed, could

CAUTION! result in damage or destruction of equipment.

Indicates a procedure or practice, which could result in injury to

WARNING! personnel or loss of life if not followed correctly.

057-336 ISSUE: 1.6.3 Page 6 of 48

 Introduction

1.2 GLOSSARY OF TERMS

Term Description
Application The application is the program that allows the DSEM835 to control the
machine to which it is connected.
The Application within the DSEM835 is designed and provided by the
manufacturer of the complete machine (OEM).
CAN Control Area Network. A high-speed data transmission system used
extensively within the Automotive and Off-Highway industries.
CODESYS Integrated Development Environment for programming controller
(Previously stylised applications according to the international industrial standard IEC 61131-3.
as CoDeSys) DSEM835 supports CODESYS V3.5
DSE Deep Sea Electronics Ltd. www.deepseaelectronics.com
DSE_CAN This is the CODESYS Namespace of the DSE CAN Functions Library.
Often DSE_CAN is used as shorthand to refer to DSE CAN Functions
Library.
ECU Electronic Control Unit. For example, the DSEM835 device.
Input / Output. For example, “The I/O is taken out to an external terminal
I/O
strip in the user panel”.
Integrated Development Environment. For example, the CODESYS V3.5
IDE
application that runs on the host PC is an IDE.
International Electrotechnical Commission. The standards body
IEC
responsible for IEC 61131-3 the standard to which CODESYS conforms.
High Level CAN specification dictated by S.A.E. and used by many Engine
J1939
ECUs and other CAN devices.
Range of CODESYS devices manufactured by Deep Sea Electronics Ltd
MSeries
www.deepseaelectronics.com.
Namespace is the prefix used within CODESYS to refer to functions within
Namespace a library. Functions within DSE CAN Functions Library are prefixed with
DSE_CAN. Example: DSE_CAN.CANInit(…);
Off-Highway An industrial vehicle used primarily “off road”. For example, construction
and farm machinery. A wider interpretation includes on road access
platforms, emergency vehicles and other industrial machinery, used either
on the road, or off road.
O.E.M. Original Equipment Manufacturer. The manufacturer of the overall machine
that the DSEMSeries device is a part of.
The OEM is also responsible for programming the device though they may
subcontract this to System Integrators or Programming Houses.
PLC Programmable Logic Controller. Industrial computer used primarily for the
automation of electromechanical machinery.
SAE Society of Automotive Engineers (USA)
SLOT Scaling, Limits, Offset, Transfer. The conversion specifications for J1939
data,

Page 7 of 48 057-336 ISSUE: 1.6.3

 Introduction

1.3 RELATED INFORMATION

This document refers to and is referred by the following DSE publications which are obtained from the
DSE website: www.deepseaelectronics.com or by contacting DSE technical support:
support@deepseaelectronics.com.

1.3.1 SAMPLE PROJECT FILES

This document is supplied in a Zip file along with all program listings. These are supplied as is, as
examples, and do not constitute a complete working application. The principle described in the project
may be copy/pasted or exported/imported into your own application from where they must be fully
tested. It is the programmer’s responsibility to ensure all project operate safely, as expected, and as
required.

The supplied examples use device descriptor DSEM840-02 V4.1, however the code within functions
on all DSEMSeries CODESYS devices. To convert the project to suit other devices/versions:

Right click Device

Select Update
Device…

Select Deep Sea Electronics

Select required device variant

and version

Enable Display all versions to

allow selection of previous
device versions if required

Click Update
Device after
selections
above

Click Close
when finished

057-336 ISSUE: 1.6.3 Page 8 of 48

 Introduction

1.3.2 TECHNICAL INFORMATION

NOTE: Operator Manuals also include CODESYS Software instructions except for
DSEM870 and DSEM812 whose CODESYS manuals are provided separate from the Operator
manual and listed separately.

DSE Part Description

057-270 DSEM240 Operator Manual
057-328 DSEM5xx Keypads Operator Manual
057-244 DSEM640 & DSEM643 Operator Manual
057-313 DSEM835 Operator Manual
057-248 DSEM840 Operator Manual
057-246 DSEM870 Operator Manual
057-320 DSEM870 CODESYS Software Manual
057-317 DSEM812 Operator Manual
057-318 DSEM812 CODESYS Software Manual

Page 9 of 48 057-336 ISSUE: 1.6.3

 Introduction

1.4 LIBRARY COMPATIBILITY AND VERSION NUMBERING

NOTE: It is strongly recommended to use DSE CAN Functions Library V1.5 and above.
Change notes are listed elsewhere in this document.

Library version numbering is used to indicate compatibility and is in the form X.Y.Z

Version Number Title

Portion
X Major version
Y Minor version
Z Build
Description
Upon library updates, this number changes only when
an existing function changes, breaking compatibility with
code written for previous versions. Minor Version also
changes at this point, usually resetting to zero (0).
Where Major Version remains the same at a library
update, this indicates that there are no changes to
existing functions, meaning code utilising earlier library
versions, where Major Version is the same, continue to
work with no changes required.
Upon library updates, this number changes when new
functionality is added which does not affect code written
for versions of the library with the same Major Version.
Upon library updates, this number changes only when
there are no new functions, and no changes to existing
functions. Typically, this occurs when there are changes
to comments, online documentation, hot fixes, etc
Where the version number is shortened to X.Y, this
implies that either Z=0 or that it is irrelevant in the
context in which it is written.

Example1:

Code is written utilising DSE_CAN V1.3

The user can safely update their project to include DSE_CAN V1.6. There are no changes to the
existing functionality of the functions available in DSE_CAN V1.3, however new functions are
available should the programmer wish to take advantage of them.
This allows users of legacy libraries V1.0 to V1.4 to safely update to DSE_CAN V1.5 or above, taking
advantage of the latest bus recovery functionality without having to change application code.

Example2:

Code is written utilising DSE_CAN V1.6

A future (hypothetical) update adds a new mandatory input to an existing function. This breaks
compatibility with code written to use previous versions of the same function, hence the library version
becomes DSE_CAN V2.0. Changes of this nature are not commonplace. Alternatives are considered
before a Major Version Change is made.

057-336 ISSUE: 1.6.3 Page 10 of 48

 Introduction

1.5 SAFETY INSTRUCTIONS

1.5.1 GENERAL

• These instructions and examples are for authorised persons and intended as a guide to using the
library. They do not form a complete application. The device must be programmed, tested,
installed, connected, and put into operation by qualified Engineers.

• The customer is responsible for performing risk analysis of the mobile working machine and
determining the possible safety related functions.

• The user is responsible for the safe function of the application programs created. If necessary,
they must additionally carry out an approval test by corresponding supervisory and test
organisations according to the national regulations.

Page 11 of 48 057-336 ISSUE: 1.6.3

 Introduction

2 INSTALLATION

NOTE: DSE CODESYS Package is available from www.deepseaelectronics.com

NOTE: If you have an older version of DSE CODESYS Package, you do not need to
uninstall it before installing a newer version. Simply click Install and allow CODESYS to install
the new one.

Within
CODESYS
V3.5, select
Tools |
Package
Manager…

Click to select the package

downloaded from
www.deepseaelectronics.com

Click Close
when
finished

The installation process takes a few minutes so wait until it is completed.

DSE CAN Functions Library is now contained in the Library Manager of your CODESYS installation.
To use the library in a project it must be added to the project as detailed in the following section.

2.1 DSE_UTILS
Installation of the DSE CODESYS PACKAGE installs other DSE Compiled Libraries, including
DSE_UTILS. This includes a suite of conversion functions, useful for packing and unpacking data to
and from CAN messages. Online help for DSE_UTILS is included within CODESYS Library Manager.

057-336 ISSUE: 1.6.3 Page 12 of 48

 Library Usage

3 LIBRARY USAGE

NOTE: For a full list of struct members, enumerations, function blocks and functions, see
CODESYS Online Help within the Library Manager. For further details, see section entitled DSE
CAN Functions Library Online Help elsewhere in this manual.

NOTE: Ensure CAN port is initialised with DSE_CAN.CANInit before use.

NOTE: Examples shown in the following subsections are available from

support@deepseaelectronics.com.

3.1 ADD TO LIBRARY MANAGER

Before use, the library must be selected from the Library Repository and included in the Library
Manager of the project.

In this example, we have created an ‘empty’ project for DSEM840 controller.

These entries (CAN1 &

CAN2) refer to
CODESYS CAN library.
If we are using only DSE
CAN Functions Library
(and CODESYS CAN is
not being used), these Double click Library
can be removed. Manager to add libraries
to our project.

Click Add
Library

Page 13 of 48 057-336 ISSUE: 1.6.3

 Introduction

Click Advanced…

NOTE: Select Company: All Companies to allow selection of DSE Libraries produced prior
to the change of company name. All DSE Libraries are now produced under the name Deep
Sea Electronics. Legacy versions may appear with the suffix Ltd or PLC.

Select Deep Sea

Electronics to filter
selection to the
latest libraries from
DSE.

Select the version of

library you require,
usually the latest
version. For change
details, see section
entitled DSE CAN
Functions Library
Change Notes.

DSE CAN Functions

Library shown in the
Library Manager.
DSE_CAN is the
Namespace of the
library,

057-336 ISSUE: 1.6.3 Page 14 of 48

 Library Usage

3.2 DSE CAN FUNCTIONS LIBRARY ONLINE HELP

CODESYS libraries are self-documenting within the library manager. To browse available functions,
function blocks, and type definitions, browse the tree as shown below.

Click the
library the help
information
appears in the
pane below…

Browse the tree

to locate the item
to learn about… Help
information is
provided in
the lower
right pane.

Using Library Help we can see the input/output requirements of functions and function blocks and
note if any have default (initial) values. In the following example, Priority and Timeout inputs can be
omitted, the values used by the function block is indicated in the Initial column. All other inputs are
required. Outputs are always optional. Do not map them if you don’t need them in your application.

Example:
Browse the tree
Select the
to locate the item
Documentatio
to learn about…
n tab

Scope Initial column

shows if the shows default
parameter is values where
Input or applicable.
Output

Page 15 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.3 INITIALISE / DEINITIALISE THE CAN PORT(S)

NOTE: If using CAN to receive messages with 29-bit headers, set Extended Mode to
TRUE. A port cannot be used receive messages with both 11 bit headers and 29 bit headers at
the same time.

3.3.1 INITIALISE

NOTE: DSEMSeries devices are fitted with either 1,2,3, or 4 CAN ports depending upon
product type.

NOTE: An individual port is initiailsed for reception of EITHER 11-bit headers (CAN2.0A)
or 29-bit headers (CAN2.0B).

Before use, the CAN port must be initialised. This is usually one off operation, usually executed at the
beginning of the application execution but is also required after a deinitialisation of the port.

Example:
FALSE: 11-bit headers (CAN2.0A)
TRUE: 29-bit headers (CAN2.0B)

The CAN port is now ready for use.

Usage instructions for CAN RAW and J1939 are included in the following subsections.

3.3.2 DE-INITIALISE

NOTE: After calling the CANDeinit function the port cannot be used by DSE_CAN
functions. Transmit and Receive functions report NO_DRIVER when calling them if set to use a
port that is not initialised. Receivers must then be ‘destroyed’ by calling them with
RxID:=16#FFFFFFFF before the port is reinitialised and the receivers recreated by calling them
again as usual.

Where it is required to de initialise the CAN port, for example to change baud rate,

First delete any receivers in use on this port in the application, for example:

Then call CANDeinit:

And now, the port is ready to be re-initialised.

057-336 ISSUE: 1.6.3 Page 16 of 48

 Library Usage

3.4 CAN RAW

NOTE: Ensure CAN port is initialised with DSE_CAN.CANInit before use. Attempting to
use an uninitialized port results in NO_DRIVER error being reported.

Functions for CAN Raw are found in the applicable library tree:

Click the
library the help
information
appears in the
pane below…

Click +
alongside
Raw

CAN Raw provides a medium level interface to the CAN hardware and allows CAN messages to be
sent and received. The name Raw is used as there are no restrictions governing the message ID
and/or message data bytes (sometimes called payload).

CAN 2.0A (11-bit message header) and CAN 2.0B (29-bit message header) are supported.

At the lowest level, CAN Raw functions are used to send messages between devices. For example,
sending messages from DSEM64x device to a DSEM8xx device to allow the display of values
measured by DSEM64x. Conversely, DSEM8xx may send messages to M64x as control messages
indicating button presses, user touchscreen commands, and other control information.

Additionally, CAN Raw functions are used to provide support for higher level CAN protocols such as
S.A.E. J1939, used extensively in off-highway diesel engines and other industrial machinery in
addition to transducers, and expansion devices including remote keypads and displays.

J1939 functions found within DSE CAN Functions Library also make use of the CAN Raw functions.
For further details of J1939 functions, see section entitled CAN J1939 elsewhere in this document.

Page 17 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.4.1 RECEIVING MESSAGES

NOTE: It is recommended that each message to be received has a function block instance
dedicated to it.

NOTE: Each function block receiver has its own incoming message buffer. This allows
multiple function blocks to receive the same message if required.

NOTE: Once a receiver has been instantiated, it continues to buffer messages with
matching ID. To handle the buffer, call the receiver function regularly. Failure to do so may
cause buffer overflow should the buffer fill with unhandled messages. Call a receiver with ID
16#FFFFFFFF to destroy the receiver if no longer required.

DSE CAN Functions Library includes function blocks to read CAN messages.
A summary is given below, with examples in the following subsections.

Function Block Description

CANReceive This is the most used receive function.
Used to receive CAN messages with specific
message IDs. Where multiple messages with the
same ID are received since the last call to the
function, only the last received data is retained.
CANReceiveSingle
NOTE: Care must be taken not to block
program operation if the transmission frequency
of the received message is excessive.
If a new task starts before the last one
completes, an Exception Error occurs,
application execution ceases, device LED (where
fitted) shows Static RED, and the device event
log registers Processor Overload.

Advanced.
Used where multiple messages of the same ID are
received between function calls, and it is necessary
to receive them all, and not just the latest one.
During the task cycle, we must analyse the buffer
and retrieve messages until no more remain, before
moving to the next task cycle.
CANReceiveMask
NOTE: Care must be taken to ensure that
excessive numbers of messages are not
received. Ensure the mask is not ‘too loose’.

Advanced.
An AND mask is provided to mask bits within the
message ID. This is used (for example) in J1939 to
receive all messages of a specified PGN while
ignoring message priority, or sender node ID.
Bits in input Mask are applied to the input RxID when
looking for an ID match with the incoming messages.

057-336 ISSUE: 1.6.3 Page 18 of 48

 Library Usage

3.4.1.1 CANRECEIVE

Example receiving a message with 29-bit ID

3.4.1.2 CANRECEIVEMASK

NOTE: Available in DSE CAN Functions Library V1.6 onwards.

Example receiving a message with 29-bit ID. The mask is used to mask the last byte of the ID so that
any message with ID matching the rest of the ID is received, with the last byte ignored.

Page 19 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.4.1.3 CANRECEIVESINGLE

NOTE: Care must be taken not to block program operation if the transmission frequency
of the received message is excessive. A simple method is to employ a timer as shown in
example 2.
If a new task starts before the last one completes, an Exception Error occurs, application
execution ceases, device LED (where fitted) shows Static RED, and the device event log
registers Processor Overload.

Example 1: Showing minimal usage that will cause blocking if the message is placed on the bus by
the transmitting device at too high a frequency.

Example 2: Showing the use of a timer to ensure the receiver does not block the continuation of
program execution for an excessive time.

057-336 ISSUE: 1.6.3 Page 20 of 48

 Library Usage

3.4.2 TRANSMITTING MESSAGES

3.4.2.1 CANTRANSMIT

NOTE: It is recommended that each message to be transmitted has a function block

instance dedicated to it.

NOTE: Consider the time between function calls (usually the task cycle time). This implies
both the minimum time, and resolution of the timing, between messages from the same
function block.

NOTE: A message sent over CAN is always Acknowledged by another CAN node (any
CAN node can Acknowledge when it sees a message on the bus). Should an Acknowledge not
be received by a sending node, this is counted as a Transmission Failure.
DSE_CAN.CANDiagnosis function is used to check the BUSSTATE to determine such failures.
For further details, see section entitled Helper Functions | CANDiagnosis elsewhere in this
manual.

Allows CAN messages to be sent with a parameter Frequency to prevent the message being sent
more often than specified. Typical usage scenarios are:

1. Call the function block once per task cycle. Set Frequency to ensure messages are sent no
more often than (example) once every 100 ms.
2. Call the function block when required. For example, upon change of a value. Set Frequency
to 0 to ensure the message sent every time the function block is called. Set Frequency to
value to prevent messages being sent too often.
3. Using a combination philosophy, monitor a variable. If it changes, call the function block with
Frequency set to 0. The message is sent immediately. If the variable does not change, call
the function block with Frequency set to 1 s. The message is now sent upon change and
every second if there is no change.

Upon the call to the CANTransmit block, the time is checked. If the elapsed time since the last call is
less than Frequency, the message is not sent and NewMessage is set to FALSE. If the elapsed time
is greater than, or equal to, Frequency, the message is sent, and NewMessage is set to TRUE.
NewMessage allows us to check if the message was sent during this cycle. For example, we can use
this to implement counters, incrementing each time the message is sent and unchanging if the call did
not result in message being sent as the elapsed time did not require it.

Example: Showing how to send a message.

Page 21 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.4.3 ADDING A WATCHDOG TO CAN RAW

NOTE: If using CAN Raw to read J1939 messages, consider using

DSE_CAN.J1939Receive. This has an inbuilt TON to provide watchdog capability.

Individual programmers have their own requirements for what should occur given a failure of either
the complete CAN system, or failure of a specific incoming message.

Typically, a timer is used (TON) that is reset upon reception of one or more messages. Multiple timers
are used to provide detection of multiple failures.

Example:

057-336 ISSUE: 1.6.3 Page 22 of 48

 Library Usage

3.5 CAN J1939

NOTE: J1939 functions are available in DSE CAN Functions Library V1.6 onwards.

NOTE: Ensure CAN port is initialised with DSE_CAN.CANInit before use.

While CAN Raw functions are available to be used with J1939, use with this higher level protocol is
aided by the provision of function blocks specifically related to it.

Functions for CAN J1939 are found in the applicable library tree:

Click the
library the help
information
appears in the
pane below… Click +
alongside
J1939

3.5.1 RECEIVING MESSAGES

DSE CAN Functions Library includes function blocks to read J1939 messages.
A summary is given below, with examples in the following subsections.

Function Block Description

J1939Receive Used to receive messages with the specified
parameters. (Priority, Datapage, PDU Format, PDU
Specific and the sender’s Source Address).
This function block receives the latest message with
matching parameters since the last time the function
block was called.
Read_xxxx Functions are provided to read the most commonly
required J1939 PGNs and present the received data
in structures.
Example include (but are not limited to)
Read_EEC1
Read_ET1
Read_HOURS
Read_EFLP1
J1939_DM1_DM2 Function block to read the Active (DM1) and Historic
(DM2) Diagnostic Trouble Codes from an ECU.
This function block supports single messages and
Broadcast Announce Messages (BAM multipart
messages).
Where it is required to read both DM1 and DM2, two
function blocks are required, one for each.

Page 23 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.5.1.1 J1939_RECEIVE

NOTE: J1939_Receive obtains the data in the last message matching the input
requirements. If you wish to receive all matching messages seen on the bus since the last call
to the function block, use CAN Raw function DSE_CAN.CANReceiveSingle instead.

NOTE: If you don’t know the values required for Priority, DataPage, PGN, and
SourceAddress you can determine these from the 29-bit ID of the message, or use the CAN
RAW function DSE_CAN.CANReceive instead.

Used to receive a J1939 message, J1939_Receive is a wrapper for DSE_CANReceive. It is not

required to know the message ID, this is calculated from the given parameters to the inputs (Priority,
DataPage, PGN and SourceAddress.) and provided as an output for diagnostics.

Example showing how to receive PropB_21 (PGN 16#FF21) with Priority 6 from SourceAddress
16#03.
This example uses T#5s for Timeout. In practice we should set this value to at least 2.5 times the
transmission period. (eg if the message is transmitted by the sender every 50 ms, use Timeout of at
least 125 ms). Datapage is often 0, however check this against the 29-bit message ID or consult the
manufacturer of the equipment transmitting the message.

057-336 ISSUE: 1.6.3 Page 24 of 48

 Library Usage

3.5.1.2 READ_XXXX

NOTE: Common J1939 PGNs are provided, readymade, for your convenience. If a
particular PGN is not available, or additionally functionality is required, use
DSE_CAN.CANReceive to receive the data and apply the scaling and offset within your own
custom function. This provides full flexibility for the full range of J1939 PGNs.

For commonly required J1939 messages, a collection of readers is provided. Browse the folder
structure in the library manager to see the functions available in the latest version of the library.

Example list from Library Manager:

Example: Showing how to read typical parameters from a CAN J1939 engine.

Page 25 of 48 057-336 ISSUE: 1.6.3

 Introduction

Advanced

A hidden array is available, containing the raw contents of the CAN message. This is useful if you
want to retransmit the raw data, perform other calculations on the raw data, for diagnostic functions,
and more.

Example:

Array to store the

contents of a single
CAN message

Copying the received raw data into a

temporary array.
The .Data array contains the data of the last
received message with the matching ID.

057-336 ISSUE: 1.6.3 Page 26 of 48

 Library Usage

3.5.1.3 J1939_DM1_DM2

NOTE: This function is not supported by DSEM640 or DSEM643.

NOTE: For J1939 ‘Multipart’ messages, this function block supports Broadcast Announce
Messages (BAM).

NOTE: The use of text lists is not supported by DSEM835. When using with M835, inputs
SPNList, FMIList and bGetStrings are ignored and conversion to strings is not available.

NOTE: For suitable text lists to pass as inputs to SPNList and FMIList, see DSE_UTILS
library.

Used to listen for and receive DM1 or DM2 messages from a specified node address. Where both
DM1 and DM2 reception is required, two function blocks must be used. Input PGN specifies which
messages are to be received.

Basic example using the default settings of the function block. This is the common way to use the
function block, where the remaining inputs take on the defaults values as indicated in the table below.

Function block I/O List

Name Type Default Comment

Input NetID eCANList CAN_1 CAN Port to use
PGN eJ1939_PGN PGN to look for (DM1 or DM2)
usSenderSA USINT 16#0 Source address of the sender
RetentionTime TIME TIME#2s0ms Time a DTC is held after it is no longer
received. For DM2, consider your RQST
frequency.
IgnoreList ARRAY Any SPN/FMI pair in this list is not added to
[1..10] OF the DTC list.
SPN_FMI_t
SPNList STRING ‘’ Path to SPN TextList (not supported by
M835).
FMIList STRING ‘’ Path to SPN TextList (not supported by
M835)
bGetStrings BOOL FALSE Get SPN/FMI strings from list (slower
operation) Forced to FALSE for M835
Output bNewMessage BOOL TRUE - a new DM1/2 message received
last cycle

Page 27 of 48 057-336 ISSUE: 1.6.3

 Introduction

Name Type Default Comment

bBusy BOOL Multipart in progress. Use this to inhibit
requests for other multipart messages
Count USINT How many DTCs are in the list
Lamps DM1Lamps_t Status of the ECU Lamps
DTCList ARRAY List of DTCs
[1..50] OF A pointer to this list can be used as the
DTC_t pDTCList input to the DTCScroller function
block.
Flasher Flasher_t Optional output to use to flash visualisation
items so that they can flash in synchronism
with items (eg Fault Lamps) that may be
flashing under control of this function.

057-336 ISSUE: 1.6.3 Page 28 of 48

 Library Usage

3.5.2 TRANSMITTING MESSAGES

3.5.2.1 J1939_TRANSMIT

NOTE: It is recommended that each message to be transmitted has a function block

instance dedicated to it.

NOTE: Consider the time between function calls (usually the task cycle time). This implies
both the minimum time, and resolution of the timing, between messages from the same
function block.

NOTE: A message sent over CAN is always Acknowledged by another CAN node (any
CAN node can Acknowledge when it sees a message on the bus). Should an Acknowledge not
be received by a sending node, this is counted as a Transmission Failure.
DSE_CAN.CANDiagnosis function is used to check the BUSSTATE to determine such failures.
For further details, see section entitled Helper Functions | CANDiagnosis elsewhere in this
manual.

Used to transmit a J1939 message, J1939_Transmit is a wrapper for DSE_CANTransmit. It is not

required to know the message ID, this is calculated from the given parameters to the inputs (Priority,
DataPage, PGN and SourceAddress.) and provided as an output for diagnostics.

Allows CAN messages to be sent with a parameter Frequency to prevent the message being sent
more often than specified. Typical usage scenarios are:

1. Call the function block once per task cycle. Set Frequency to ensure messages are sent no
more often than (example) once every 100 ms.
2. Call the function block when required. For example, upon change of a value. Set Frequency
to 0 to ensure the message sent every time the function block is called. Set Frequency to
value to prevent messages being sent too often.
3. Using a combination philosophy, monitor a variable. If it changes, call the function block with
Frequency set to 0. The message is sent immediately. If the variable does not change, call
the function block with Frequency set to 1 s. The message is now sent upon change and
every second if there is no change.

Upon the call to the J1939_Transmit block, the time is checked. If the elapsed time since the last call
is less than Frequency, the message is not sent and NewMessage is set to FALSE. If the elapsed
time is greater than, or equal to, Frequency, the message is sent, and NewMessage is set to TRUE.
NewMessage allows us to check if the message was sent during this cycle. For example, we can use
this to implement counters, incrementing each time the message is sent and unchanging if the call did
not result in message being sent as the elapsed time did not require it.

Example: Showing how to send a message.

Page 29 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.5.2.2 J1939_REQUEST

NOTE: As a request message header to a specific node is the same, regardless of what
PGN is being requested, only one request message can be sent to that node per task cycle. If
multiple requests are made inadvertently, only the last one is sent.

Builds a request message for the specified PGN. You must also provide a listener to receive the
requested message.

Example: Showing sending a request every 60 seconds for node 00 (typically the engine ECU) to
transmit HOURS PGN (containing Running Hours of the engine).

057-336 ISSUE: 1.6.3 Page 30 of 48

 Library Usage

3.5.3 ADDING A WATCHDOG TO CAN J1939

Individual programmers will have their own requirements for what should occur given a failure of
either the complete CAN system, or failure of a specific incoming message.
Consider failure of the DD (Dash Display) message. This is carrying instrumentation data for the dash,
including Fuel Level. If this message is not seen on the bus, it could be considered as a ‘minor’
failure. The instrumentation value should be changed on the display, to alert the user that it is not
current data (hide the value or change it to ####). However, we can allow the engine to continue
running.

DSERead_xxxx function blocks include the Timeout input and Valid output to assist with this, seen in
use in the example in the section entitled Receiving Messages | J1939_Receive and Receiving
Messages | Read_xxxx elsewhere in this document.

Depending upon requirements we can use OR to consider the failure of one or more messages or
handle them all individually. This is the decision of the programmer and ultimately the specifier of the
finished application.

Page 31 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.5.4 HELPER FUNCTIONS

In addition to Transmission and Reception functions, DSE CAN Functions Library provides a
collection of helper functions to assist with common requirements within a J1939 ECU.

3.5.4.1 SLOT

NOTE: Commonly used SLOTs are included within DSE_CAN. Where other conversions
are required, you can add a custom UnitConversion object to your project and insert your own
conversions and additional SLOTs for use within your project.

Conversion from J1939 data to/from actual instrumentation values is specified by J1939 SLOT
entries.
SLOT is an acronym from Scaling, Limits, Offset, Transfer and describes how to perform the data
conversion.

DSE CAN Functions Library contains a CODESYS Conversion object for the most used SLOTs. While
they are used internally by the Read_xxxx function blocks, they are available for programmers to use
in their own applications.

Example from CODSYS Library Help.

J1939_SLOT
within the
library help.

Conversion name within DSE_CAN.J1939_SLOT

Eg
rValue:=DSE_CAN.J1939_SLOT.SAEtp01.Convert(123);

057-336 ISSUE: 1.6.3 Page 32 of 48

 Library Usage

3.5.4.2 J1939_DTCSCROLLER

J1939 DTC Scroller is used in conjunction with a previously acquired list of DTCs (Diagnostic Trouble
Codes) to provide a method of automatically or manually scrolling through the list of DTCs to allow
one of them to be shown on the device display.
A typical use of this is to scroll through active DTCs every two seconds, displaying only one at a time.
The user can be (optionally) provided with a method to pause this automatic scrolling and (again
optionally) cycle manually through the available DTCs. This is particularly useful for applications
where the visualisation area available for DTCs is limited, or to provide a method of sending DTCs
one at a time to another device for display.

This function is designed to be used in conjunction with the DTCList output returned from the
J1939_DM1_DM2 function block.

Example 1 showing DM1 reception and the use of the DTCScroller utilising the DM1 DTCList.

Example 2, showing DM1 reception and the use of the DTCScroller utilising the DM1 DTCList. M840
buttons UP and DOWN are used to manually scroll the active DTC list.

Page 33 of 48 057-336 ISSUE: 1.6.3

 Introduction

3.5.4.3 J1939_DTCSCROLLER FUNCTION PARAMETERS

Name Type Default Comment

Input pDTCList POINTER TO Intended to be a pointer to the DTCList from
ARRAY[1..50] the DM1_DM2 function
OF DTC_t
ScrollTime TIME T#5s Time to auto scroll to the next DTC.
PageTime TIME T#30s Source address of the sender
AutoScroll BOOL TRUE FALSE: DTC output ceases scrolling.
TRUE: DTC autoscroll occurs.
Up BOOL Rising edge moves to display the previous
DTC in the list. Wrap around to the last DTC
in the list occurs when moving up from the
first DTC.
Down BOOL ‘’ Rising edge moves to display the next DTC
in the list. Wrap around to the first DTC in
the list occurs when moving down from the
last DTC.
Output Change BOOL Indicates a change in the output DTC either
from auto or manual scroll.
MaxDTC USINT How many DTCs are in the current list.
CurrentDTC USINT Index number of the currently output DTC.
Can be used to show a ‘x out of y’ value to
indicate the current DTC and number of
DTCs
Example, Showing DTC 1 of 7 with the
values coming from MaxDTC and
CurrentDTC
DTC DTC_t Structure of the currently output DTC.
SPN: Suspect Parameter Number
sSPN: SPN as a descriptive string (when
available)
FMI: Failure Mode Indicator
sFMI: FMI as a descriptive string (when
available)
OC: Occurrence Count
SA: Source address from where the DTC
came.
TimeStamp: System time that the DTC was
received.

057-336 ISSUE: 1.6.3 Page 34 of 48

 Library Usage

3.5.4.4 J1939_BUILDTSC1

NOTE: Only call BuildTSC1 when necessary. Each time it’s called, the message counter is
incremented so must only be called after a previous transmit. The example below shows how
to achieve this, using the .NewMessage output from the transmitter function.

Builds the TSC1 (Torque and Speed Control) message data necessary to send to an ECU. This
includes the message counter and checksum.

Example1: Showing how to send TSC1 message every 10 ms within a faster task. Ensure the task
containing this is set to 10 ms or faster. This may require you to create a high priority dedicated task
for this, not slowed or affected by the main (slower) task handling the visualisation and non-time-
critical functions. See Example2 below for how to do this in a dedicated task.

See overleaf for Example2.

Page 35 of 48 057-336 ISSUE: 1.6.3

 Introduction

Example2: Showing how to send TSC1 message every 10 ms within a small task. This sends the
TSC1 message every cycle so the task cycle time must be set to match the TSC1 transmission rate.
The advantage with this method is that this task is used exclusively for the TSC1 message so has a
more ‘regular’ cycle time, not affected by other code.

“Slow” (100 ms)

task for the general
application
functions.

“Fast” (10 ms) task

to send the TSC1
messages.

057-336 ISSUE: 1.6.3 Page 36 of 48

 Library Usage

3.6 CANDIAGNOSIS

NOTE: Parameter names denoted by * are incorrectly spelled. In the interest of

compatibility with existing applications, there is no current plan to change this.

NOTE: As CANDiagnosis is a function, there is no memory of the output values. They

must be mapped to local variables for monitoring.

Function CANDiagnosis is used to monitor the CAN port status.

Scope Name Type Comment

Return CANDiagnosis ERROR ERROR enum is from CL2 library, accessible with
DSE_CAN.CL2.ERROR
Input NetID USINT CAN Channel ( 0 = CAN1 )
Use DSE_CAN.eCANList.
Output Error ERROR ERROR enum is from CL2 library, accessible with
DSE_CAN.CL2.ERROR
BusAlarm BOOL FALSE: CAN is operating normally.
TRUE: CAN is in alarm state. Sending and receiving
messages is not possible. Use
DSE_CAN.CANDeinit and subsequently
DSE_CAN.CANInit to reset and restart the CAN. If
the fault remains, BusAlarm recurs.
BusState BUSSTATE BUSSTATE enum is from CL2 library, accessible
with DSE_CAN.CL2.BUSSTATE

For description of the states, see subsection entitled

BUSSTATE.
BusLoad USINT Approximate loading of the bus
LostMessages USINT Number of lost messages
ReceiveCounter UDINT Number of received messages
ReceiverErrorCounter USINT Number of errors detected in reception.
*ReceiveQueueLenght USINT Length of the incoming receive buffer (messages
not yet handled by CODESYS application)
This value should always be going down (as
messages are read), or zero (as the incoming
messages are handled immediately).
TransmitCounter UDINT Number of transmitted messages. If this value is
changing, it means the messages being placed on
the bus are being acknowledged by another device
on the bus.
TransmitErrorCounter USINT Number of errors detected in reception (example
unacknowledged messages)
This number is decremented upon a successfully
sent message.
*TransmitQueueLenght USINT Length of the outgoing transmit buffer (messages
not yet sent)
Typically this will be going down or zero.

Page 37 of 48 057-336 ISSUE: 1.6.3

 Introduction

Example: Showing how to obtain diagnostics of the specified CAN port.

3.6.1 BUSSTATE

NOTE: Parameter names denoted by * are incorrectly spelled. In the interest of

compatibility with existing applications, there is no current plan to change this.

BusState comes from the CL2 (CAN Low Level) library and differs slightly between controllers.

3.6.1.1 DSEM640 & DSEM643

BusState Description
UNKNOWN TransmitCounter increasing upon messages being sent means the CAN network is OK.

Where TransmitCounter, TransmitQueuelenght*, and TransmitErrorCounter are all zero (0),

this indicates a major bus fault such as a short between H and L.
WARNING TransmitErrorCounter >95

Sent messages are not being acknowledged. Ensure the receiver is correctly connected
and configured.
Upon correction of the fault, TransmitErrorCounter decrements with each sent message
that is correctly acknowledged.
BUSOFF Bus is disconnected from the network. Check connections, cable, termination etc.

057-336 ISSUE: 1.6.3 Page 38 of 48

 Library Usage

3.6.1.2 DSEM840

BusState Description
ERR_FREE CAN network is OK

PASSIVE CAN Network is not active.

ACTIVE CAN network is operating; however, errors are/were present. If the fault has been
corrected, the state will change when enough messages are received to bring down the
error count.
BUSOFF Bus is disconnected from the network. Check connections, cable, termination etc.

3.6.1.3 DSEM870 & DSEM812

BusState Description
ACTIVE CAN network is OK

WARNING Sent messages are not being acknowledged. Ensure the receiver is correctly connected
and configured.
Upon correction of the fault, TransmitErrorCounter decrements with each sent message
that is correctly acknowledged.
BUSOFF Bus is disconnected from the network. Check connections, cable, termination etc.

Page 39 of 48 057-336 ISSUE: 1.6.3

 Library Applications

4 LIBRARY APPLICATIONS
4.1 DATA TRANSMISSION

NOTE: When transmitting data between DSE MSeries devices, consider using functions
within DSE_UTILS library. Examples include CANTransmit_REAL and CANReceive_REAL
which transmit the REAL values as IEE754 format with no loss of precision.

A common use of CAN is to transmit data between DSE MSeries devices.

A CAN message contains 8 bytes of data. To transmit information between devices the programmers
of the device must specify the data contents of each message. This allows them both to convert the
data correctly.
J1939 is one such specification that defines the conversion method of thousands of data entries and
provides Proprietary areas allowing programmers to define their own data structure within those
areas.

4.1.1 J1939

J1939 is useful to allow us to use this data specification for our own needs.
Example 1: DSEM8xx could be programmed to listen for CI (Cab Illumination) messages and use
the value to adjust the display backlight.

Example 2: DSEM64x could be programmed to send its measured battery voltage within a VEP1
(Vehicle Electrical Power) message for reception and display by a DSEM8xx display.

4.1.2 CAN RAW

With CAN Raw, the programmers must define all data themselves.

While this manual does not describe the data structure of CAN messages, the following examples
show some methods than can be used to transmit non integer data.

057-336 ISSUE: 1.6.3 Page 40 of 48

 Library Applications

4.1.3 REAL VALUES

The simplest way to transmit REAL (floating point) numbers over can is to decide upon the resolution
of the data to be sent.

Example: Transmit Battery Voltage over CAN.

• We have the value in a REAL variable. (ie 13.74562423245 V)

• We decide that 0.1 V resolution is suitable.
• We can take the measured battery volts, multiply by 10. (ie 137.4562423245)
• Convert to BYTE using REAL_TO_BYTE. (ie 137).
• We can transmit the value 137 in a single byte over CAN.
• The receiving device retrieves the value, and converts to REAL using BYTE_TO_REAL (ie
137.000000000000)
• It then divides by 10 (ie 13.700000000)
• We have transmitted battery voltage 13.74562423245 and received 13.70000000

By choosing larger multipliers we can increase resolution. However, this increases the magnitude of
the value so we may have to convert the value into different integer types.

Data Type Maximum CAN bytes required to transmit the data

BYTE / USINT 255 1 (1/8 of a CAN message)
WORD / USINT 65535 2 (1/4 of a CAN message)
DWORD / UDINT 4294967295 4 (1/2 of a CAN message)
LWORD / ULINT 264-1 8 (an entire CAN message)

4.1.3.1 ADVANCED

NOTE: DSE_UTILS library includes function blocks to do this. CANTransmit_REAL and

CANTransmit_LREAL for example.

Experienced programmers will know that REAL variables are 32 bits, and LREAL are 64 bits. As a
CAN message holds 64 bits of data, we can UNION REAL and DWORD and transmit two of these in
one CAN message, or UNION LREAL and LWORD and transmit one of these in a CAN message.
Use another UNION in the receiver to convert back. This method is ‘lossless’.

Page 41 of 48 057-336 ISSUE: 1.6.3

 Library Applications

4.1.4 BOOL

Each BYTE in the CAN message holds 8 bits. This can hold 8 BOOL values meaning one CAN
message holds up to 64 BOOL variables (!).

Example:

4.1.5 STRING

STRING types are not suitable for sending over CAN. There are two main options.

1. (Recommended): Decide upon a fixed STRING list. Instead of transmitting a string over
CAN, transmit the string number. This will consume only one or two bytes in a single CAN
message. The receiving device uses the received value to know what string to display.
2. (Not Recommended): STRING type. A CODESYS STRING is ASCII (values 0 to 255). Each
character is one BYTE. Copy the characters into the CAN message BYTEs. A CAN message
carries 8 BYTES. Multiple messages are required if the word (STRING) is longer than 8
characters.
3. (Not Recommended): WSTRING type. A CODESYS STRING is UNICODE (values 0 to
65535). Each character is two BYTEs. Copy the characters into the CAN message BYTEs. A
CAN message carries 8 BYTES. Multiple messages are required if the word (WSTRING) is
longer than 4 characters.

057-336 ISSUE: 1.6.3 Page 42 of 48

 Library Applications

4.2 LITTLE ENDIAN?

J1939 (among other CAN protocols) use Little Endian for values greater than 8 bits. Little Endian
simply refers to the fact that the most significant byte precedes the lower significant bytes in the CAN
message.

Example1, the following message contains four 16 bit numbers, they are displayed below in
hexadecimal for convenience.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8

00 15 20 65 35 A6 35 2E

The four values are:

Value 1 Value 2 Value 3 Value 4

0x1500 0x6520 0xA635 0x2E35

Example2, the following message contains two 32 bit numbers, they are displayed below in
hexadecimal for convenience.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8

A5 1B 21 6C 35 A6 35 2E

The two values are:

Value 1 Value 2
0x6C211BA5 0x2E35A635

Converting the Bytes to the actual Values is performed in one of several ways, detailed below. Which
method you choose is down to personal preference and listed overleaf in order of ‘ease of
programming’.

Page 43 of 48 057-336 ISSUE: 1.6.3

 Library Applications

4.2.1 DSE_UTILS

DSE_UTILS compiled library provides several functions for data conversion. These include, but are
not limited to BYTES_TO_WORD, BYTES_TO_LWORD, WORD_TO_BYTES, LWORD_TO_BYTES.

Example, the following message contains four 16 bit numbers, they are displayed below in
hexadecimal for convenience.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8

00 15 20 65 35 A6 35 2E

The 4th Value, in Bytes 5 and 6 is converted using Structured Text and placed into a WORD as
follows.

DSE_UTILS.BYTES_TO_WORD(B0:=Byte6, B1:=Byte5, W=>myWord);

4.2.2 BIT SHIFTING / MULTIPLICATION

This method does not require the DSE_UTILS library.

Example, the following message contains four 16 bit numbers, they are displayed below in
hexadecimal for convenience.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8

00 15 20 65 35 A6 35 2E

The 4th Value, in Bytes 5 and 6 is converted by shifting the Byte 6 into the Most Significant Byte of a
WORD and then putting Byte 5 into the Least Significant Byte of the same WORD.

myWord:=SHL(Byte6,8) + Byte5;

Bitshifting by 8 is the same as multiplying by 256 so is equivalent to :

myWord:=( Byte6 * 256 ) + Byte 5;

057-336 ISSUE: 1.6.3 Page 44 of 48

 Library Applications

5 TROUBLESHOOTING
The below are suggestions answering frequently asked questions about the device.

Symptom Suggestion
Function Blocks return This means that the CAN port has not been initialised using
NO_DRIVER error DSE_CAN.CANinit.

• Initialise the port with DSE_CAN.CANInit. This should

be done only once in the application, typically within a
user Init type function.
• Ensure the port is initialised by the same library that is
using it. For example, if the port is initialised by
DSE_CAN V1.6, another version of the DSE_CAN
library cannot use the port as it is not initialised within
that version of library.
• If the port is deinitialised within the application (for
example to reset an error), ensure to reinitialise it again
before the next use. For example, the user Init function
that is called at program start could be called again.
• If the port was previously initialised and the library
version is changed within the project, ensure to select
Build | Clean All and upload the project to the device.
This forces a full download (rather than changes only)
and ensures the device is running with the same
version library as that included in the project file.
Messages are not being • Ensure Extended Mode in the call to DSE_CAN.CANInit
received is set to TRUE to allow reception of J1939 29-bit
message headers.
• Use a PC CAN tool (such as PCAN) along with
software such as PCAN View or BUSMASTER to check
the message required is visible on the bus. Check the
message ID matches that configured in the receive
function in the application code.
• CAN Raw Functions: Check the Rx ID of the message
matches the incoming message.
• CAN Raw Functions: DSE_CAN.CANReceive
functions retrieve only the last message in the buffer
with the matching ID. To receive all messages since the
last task cycle, use DSE_CAN.CANReceiveSingle
instead.
• CAN J1939 Functions: Check the Priority, Datapage
(typically 0), PGN and source address are correct. Use
the function block output ID to verify these against the
incoming message.
• CAN J1939 Functions: DSE_CAN.J1939_Receive and
DSE_CAN.Read_xxx retrieve only the last message in
the buffer with the matching ID. To receive all
messages since the last task cycle, use
DSE_CAN.CANReceiveSingle instead.
• To receive multiple messages, multiple receivers are
required. You can instantiate as many as you like,
however use one instance for each message.

Page 45 of 48 057-336 ISSUE: 1.6.3

 Troubleshooting

Symptom Suggestion
DM2, HOURS or ATIS These messages are usually (not always) sent On Request.
messages are not being You will need to setup a request message to request them.
received. It is recommended to request them only when necessary, for
example when opening a Visualisation page that displays them.

DM2 requests must not be sent too often as the DM2 message
reply is likely to be a multipart message, taking up bus
bandwidth.
I need to send fast CAN • Split the task into smaller tasks.
messages, every 10 ms, but a • If possible, keep CAN transmission to a separate, faster
fast task cycle is not possible task with higher priority than the other tasks.
due to the amount of code in the • Set the CAN task to priority 17, and your other tasks
task. priority 18 or lower. (Higher number=lower priority). This
keeps the internal CAN receiver task (fixed at priority
16) higher priority than your other tasks.

057-336 ISSUE: 1.6.3 Page 46 of 48

This Page is Intentionally Blank
This Page is Intentionally Blank