Advanced functionalities

2nd Part CANopen and CoDeSys pbF

Advanced functionalities NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

1

12.02.2015

2

12.02.2015

3

CoDeSys pbF and CANopen 2nd part: presentation overview

1. Review: CANopen functionality and CoDeSys pbF: - CANopen libraries - CANopen implicit variables - CANopen network operation

2. Specific CANopen functions: - Network startup - Node monitoring - Emergency message - Use of SDO telegrams

3. Some methods for diagnosing the CAN network

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

1. Review: CANopen functionality and CoDeSys pbF: - CANopen libraries - CANopen implicit variables - CANopen operation

2. Specific CANopen functions - Network startup - Node monitoring - Emergency message - Use of SDO telegrams

3. Some methods for diagnosing the CAN network

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

1

CANopen under CoDeSys pbF: libraries and Global Variables • If the CANopen network is selected (Master declared): -CoDeSys inserts all required LIBRARIES to ensure operation of the CAN network - CoDeSys generates a list of implicit Global Variables for the CAN network along with the constants and instances of Function Blocks for CAN

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

4

12.02.2015

5

CANopen under CoDeSys pbF: CANopen libraries To ensure correct operation of the CANopen network on a CoDeSys PLC, the following libraries are used: • 3S_CanDriver.Lib to perform the basic CAN controller functions • 3S_CanOpenManager.lib the basic functions and services for CANopen • 3S_CanOpenMaster.lib the functions and services for the CANopen Master

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

CANopen under CoDeSys pbF: CANopen Implicit Variables

MAX_MASTERINDEX A constant which corresponds to the maximum number of Masters supported by the PLC configuration MAX_NODEINDEX A constant which corresponds to the number of slave nodes contained in the PLC configuration

pCANopenMaster: Instance of the Function Block CanOpenMaster (Master functionality). pCanOpenNode: Instance of the Function Block CanOpenNode (Slave management).

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

6

2

CANopen under CoDeSys pbF : CANopen operation • After successful configuration end startup (boot), the sequence of CAN network operations is as follows. CANRead(0);

(* read the CAN inbound buffer*)

pCanOpenMaster[0](); pCanOpenNode[x]();

(* network management by CANopen Master *)

pCanOpenPDO_Rx[0]();

(*receive telegrams: T_PDO-Slave �R_PDO-Master *)

(* dialogue with the CANopen Slaves *)

< run user application program > pCanOpenPDO_Tx[0]() ;

(* send telegrams: T_PDO-Master � R_PDO-Slave *)

MgrClearRxBuffer(params) NSC-F-FR/W.Gomolka

(* reset CAN inbound buffer *)

CoDeSys pbF and CANopen

12.02.2015

7

Specific CANopen functions: Startup sequence (PLC startup) 1) Resetting node 2) Checking node (type and profile) 3) Loading Configuration data (SDO) 4) Configuration of node monitoring (Nodeguarding, heartbeat) 5) Node startup 6) Initialisation of all configured PDOs

CanOpenMaster: Variable nStatus: CANopen Master status -1 : Disabled 0-2 : Startup phase 3 : Slave initialisation 4 : Slaves initialised, Start command sent 5 : Start command ended, the CANopen network is operational

CanOpenNode: Variable nStatus: Slave node status 0 : not defined 1 : The node is reset by the CANopen Master 2 : Master waits ~ 300 ms before reading object 0x1000 (Device Type). Then status changes to 3. 3 : Master starts (request 0x1000) the slave configuration with SDO messages 4 : Configuration completed and the node awaits the “Start Node” command; Command is received, status changes to 5. 5 : Normal operating status. The node receives and sends the PDO telegrams. Ditto for Master status!! 97: The “Optional” node has not been detected at startup 98: The node has responded to the “Device Type” request with a different value (EDS file) 99: “LifeTime” exceeded . Node monitoring error (Nodeguarding error)

(Transfer of PDOs) NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

8

12.02.2015

9

1. Reminder: CANopen functionality and CoDeSys pbF: - CANopen libraries - CANopen implicit variables - CANopen operation

2. Specific CANopen functions - Network startup - Node monitoring - Emergency message - Use of SDO telegrams

3. Some methods for diagnosing the CAN network

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

3

Specific CANopen functions : Controlling the Network Startup Phase • By default, the Master uses an NMT “Start” command for the configured Slave. • These commands are sent “in a burst”, which can cause problems for the slow Slaves. • The “slow” Slave may therefore ignore the command, not start up and remain in pre-operational status. • It is therefore advisable to implement the NMT command “Start All Nodes” at PLC startup • This command can be run by calling up the CanOpenMaster Block function “bUseStartAllNodes”;

pCanOpenMaster[0].bUseStartAllNodes:= TRUE; • For the same reasons, it is advisable to use the NMT command “Reset All Nodes” instead of sending the “Reset Node” command to each Slave • This command can be run by calling up the “bUseResetAllNodes” function

pCanOpenMaster[0].bUseResetAllNodes:= TRUE;

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

10

Specific CANopen functions : Controlling the Network Startup Phase

• Under CoDeSys, the best solution is to create a task that is activated by the event “start” in the PLC system • The “Start/Reset All Nodes” commands will then only be sent once, when the PLC starts up.

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

11

Specific CANopen functions : CANopen Master Phase Startup (PLC startup) 1) Resetting node

pCANopenMaster: values of variable nStatus:

2) Checking node (type and profile)

1-2: Auto-initialisation of the Functional Block

3) Loading Configuration data (SDO) 4) Configuration of node monitoring (Nodeguarding, heartbeat) 5) Node startup 6) Initialisation of all configured PDOs

3: Master sends to each configured Slave an SDO (read request) for Object 0x1000 (Equipment type). Each slave must respond to this request with its profile. If the Slave does not respond, it is deemed to be absent. If the Slave responds, the Master sends to it all configuration SDOs (one by one, with a response delay) 4: All configured Slaves have responded correctly. If the “Auto Start” option is selected, the Master sends to each Slave a startup command (Start Node) 5: CANopen network is operational on the Master side

(Transfer of PDOs) NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

12

4

Specific CANopen functions : CANopen Slave Startup phase (Boot-up) (PLC startup)

pCANopenNode: values of the variable nStatus

1) Resetting node 2) Checking node (type and profile)

-1: Slave is initialised by the NMT command “Reset Node” It then enters the Auto-initialisation stage 1-2: Auto-initialisation of the Function Block

3) Loading Configuration data (SDO) 4) Configuration of node monitoring (Nodeguarding, heartbeat)

3: Slave is in the configuration phase. It receives the SDOs from Master with configured Objects. 4: Slave has received all configuration SDOs and is awaiting a startup command from Master 5: CANopen network is operational on the Slave side

5) Node startup 6) Initialisation of all configured PDOs

(Transfer of PDOs) NSC-F-FR/W.Gomolka

CanOpenNode: The nStatus variable in case of failure 97: The “Optional” node has not been detected at startup/ no 0x1000 message 98: The node has responded to the “Device Type” request with a different value (EDS file) 99: “LifeTime” exceeded . Node monitoring error (Node guarding error) CoDeSys pbF and CANopen

12.02.2015

13

Specific CANopen functions : Controlling the Network Startup Phase Checking the Master status

• The CANopen Master starts up at the same time as the application program on the PLC • A certain amount of time is therefore necessary for the whole network to come into operation (Master and all Slaves) • Before starting the application program, the CANopen network must be operational • This means that Master must have a status (variable nStatus) of at least 5 • Therefore, the Master status has to be tested: IF pCanOpenMaster[0].nStatus = 5 THEN < application code > END_IF NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

14

Specific CANopen functions : Controlling the Network Startup Phase Checking the status of a Slave • If the CANopen Master is operational, it is possible to start the availability test for the connected Slaves • The follow sequence provides a list of non-operational Slaves (status 5) after Master has started up IF pCanOpenMaster[0].nStatus = 5 THEN FOR i := 0 TO pCanOpenMaster[0].nLastNodeNr BY 1 DO nodes[i] := 0; IF pCanOpenNode[i].bOptional = TRUE THEN nodes[i] := pCanOpenNode[i].ucNodeNr; ELSE IF pCanOpenNode[i].nStatus = 5 THEN nodes[i] := pCanOpenNode[i].ucNodeNr; END_IF END_IF END_FOR END_IF

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

(*wait for Master is up*) (*Control all configured slaves*) (*Node is configured*) (*Don't control optional slaves*)

(*if node OK, access to the node is possible*)

12.02.2015

15

5

Specific CANopen functions : Checking the status of Master/Slave during operation

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

16

Specific CANopen functions : Controlling the Network Startup Phase In case of problems: Checking the Slave configuration • During initialisation, the CANopen Master sends all Configuration SDOs to the slave. • The response to the SDO configuration telegrams is contained in the structure

pCanOpenNode[i].sdoConfig.ucAnswerBytes [0..7]; • The Slave can send an Abort Code in its response: - if the object does not exist in its Object Dictionary, - if the value is incorrect - or another configuration problem has occurred. • However, the Master does not check the contents of the response from the Slave (!!!) Therefore, it does not know if the Slave has processed the SDO or if it is configured correctly • This task must be performed in the application program by the users themselves. NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

17

Specific CANopen functions : Controlling the Network Startup Phase In case of problems: Checking the Slave configuration FOR i := 0 TO pCanOpenMaster[0].nLastNodeNr BY 1 (* Control for all Nodes *) DO FOR j := 0 TO 7 BY 1 (* test if new telegram with Slave response*) DO IF pCanOpenNode[i].sdoConfig.ucAnswerBytes[j] NodeCtrl[i].OldAnswer[j] THEN bAnswer := TRUE; EXIT; END_IF END_FOR IF bAnswer THEN NodeCtrl[i].OldAnswer := pCanOpenNode[i].sdoConfig.ucAnswerBytes; j := NodeCtrl[i].nAbort; IF j 1) *) (*Index of the CanMaster that sends the message. 0 if only one Master exists *) (* Node-Id: node number (target node) *) (* Object Index in the node OD *) (*SubIndex associated with the Index*) (* SDO command to be implemented, e.g., 16#40 to read an Object *) (*4 bytes of data (possible) *)

aAbortCode: ARRAY[0..3] OF BYTE;

(* Error Code if a request is aborted *)

dwDataBufferLength: DWORD; pDataBuffer: POINTER TO BYTE;

(* used only if there is a segmented transmission of SDOs *)

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

42

14

Specific CANopen functions : CoDeSys pbF: FB CanOpenSendSDO

VAR_OUTPUT

bWaitForAnswer: BOOL; bAnswerRec: BOOL;

(* Request sent: awaiting response from the node *) (* TRUE if the node response is correct *)

ucAnswerBytes: ARRAY[0..7] OF BYTE; iAnswerLength: INT;

(* SDO Frame: 8 bytes for the response *) (* Number of valid bytes in the response *)

bToggleUnequal: BOOL; bAbortRec: BOOL; aAbortRec: ARRAY[0..3] OF BYTE;

(* TRUE in case of a response with the Error *) (* 4 bytes with SDO Error Code *)

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

43

12.02.2015

44

12.02.2015

45

SDO: Example of an application that reads CPX-FB14 Diagnostic Objects

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

Service Data Object (SDO): Practical work

1. Modify the project by adding a task with a call from FB CanOpenSendSDO - To read the contents of an Error Register (object 1001h) - To read certain diagnostic objects from CPX-FB14 (object 2210h) 2. Test the operation of the Block by inducing the various Slave errors 3. Carry out a rapid analysis of these errors

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

15

1. Reminder: CANopen functionality and CoDeSys pbF: - CANopen libraries - CANopen implicit variables - CANopen operation

2. Specific CANopen functions - Network startup - Node monitoring - Emergency message - Use of SDO telegrams

3. Some methods for diagnosing the CAN network

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

46

CoDeSys pbF: Some methods for diagnosing the CANopen network In the case when: - the Slave is not operating correctly or is not accessible - the CANopen Master remains stuck at stage (3) - the Emergency message does not arrive, even if the Slave has a problem - etc. it is possible rapidly to retrieve some information to analyze the cause of the errors in the global variables of the 3S_CANopenMaster library. These implicit global variables are : -g_CanOpenMasterBusDiagnostics used to diagnose the Master and the CAN bus - g_CanOpenMasterNodeDiagnostics contains the information on the Master and the Slaves

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

47

CoDeSys pbF: Some methods for diagnosing the CANopen network Master Diagnostic data: structure CanOpenMasterBusDiag_Type

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

48

16

CoDeSys pbF: Some methods for diagnosing the CANopen network Master Diagnostic data: structure CanOpenMasterNodeDiag_Type

The variable: g_CanOpenMasterNodeDiagnostic[x] is used to assess the diagnostics for the Slave configured as index [x] The bytes of the DiagData[..] field contain the following information: -Bytes 4-11 contain the last Emergency Message sent by the Slave. -Byte 12 contains the node identifier (Node-ID) of the Slave -Bytes 0-3 are reserved NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

49

CoDeSys pbF: Some methods for diagnosing the CANopen network CoDeSys pbF also offers diagnosis of the CANopen network: -1- Via diagnostic data, in the words %MWxxx (Diagnostic address) -2- By the use of the Functional Blocks in library BusDiag.lib -1-

-2-

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

50

CoDeSys pbF: Some methods for diagnosing the CANopen network Master Diagnostic data via BusDiag.lib: structure GetBusState • The Diagnostic Data are stored in a structure whose physical address (Diagnostic Address) is specified when the Master is configured. • This structure: GetBusState is the same as CanOpenMasterBusDiag_Type • These data are updated every time the Master has a dialogue with the Slave

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

51

17

CoDeSys pbF: Some methods for diagnosing the CANopen network Master Diagnostic data via BusDiag.lib: Functional Block DiagGetState • If one of the participants (Master or Slave) communicates an error, the specific diagnostic data can be read with Functional Block DiagGetState

The variable EXTENDEDINFO[..] is the same as the field DiagData[..] in the implicit variable: g_CanOpenMasterNodeDiagnostic[x] And is used to assess the diagnostic of the Slave indicated by BUSMEMBERID Therefore, bytes 4 – 11 of EXTENDEDINFO[..] contain the last Emergency Message sent by the Slave.

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

52

CoDeSys pbF: Some methods for diagnosing the CANopen network Functional Block: pCANopenMaster[0] The internal variable “ a” of the FB Master is incremented each time the Master is called by the OS This can be used to check that the Master is always invoked by the CoDeSys kernel.

Functional Block: pCanOpenNode[x] The internal variable “a ” of this FB Slave is incremented each time there is a call from the Slave node This is used to check that the node is “visible” to the Master and that the Master is enabled

The 16 bits (LSB) of Object 0x1000 Device Type/Device profile Number sent by the node during startup NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

53

CoDeSys pbF: Some methods for diagnosing the CANopen network PLC-Browser CAN-Monitor A “CanMonitor” tool is implemented in the PLC-Browser. The supported commands can be displayed with the “iocanstat” command The most useful: save messages (logging) in a file

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

54

18

CANopen for the CoDeSys pbF: Network diagnosis A few final words:

• The CANopen libraries for CoDeSys offer several resources, tools and several methods for diagnosing the CANopen network • at the configuration and startup phases and • for continuous diagnostics during operations • It is difficult to give precise advice, but there are several preliminary checks that should be carried out . • The choice of method/tool depends on the user: • on their expertise in CoDeSys, on the equipment in use, and • on their familiarity with the CANopen network • The user can choose the resources and methods to suit their application and its complexity etc. NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

55

Before starting the application with CANopen: Recommended checks Prior to starting your application, you should carry out some checks on your CANopen network: - Check the configuration of the connected equipment - Check the network topology - Check the cabling and connectors

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

56

Before starting the application with CANopen: Recommended checks (cont.) Configuration of the connected equipment: 1.Check that each item of equipment has its own unique address on the network and that it complies with the configuration declared in the PLC CANopen configurator 2. Check that all the connected items of equipment are configured for the same baud rate (transmission speed)

Check the CANopen network topology 1. Check the maximum distance between the two most distant nodes (bus length). 2. If their are several segments, check the segment length and the number of nodes on the segment. 3. Check the length and number of branches. NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

57

19

Before starting the application with CANopen: Recommended checks (cont.) Test and check the cabling and connectors 1.Check that the bus is disabled. The equipment must be switched off. 2. Check the resistance between CAN_L and CAN_H: - if > 65 Ω test for - the presence of a terminating resistance and - signal continuity - if < 50 Ω test - that there is no short-circuit between the CAN signals - or that there are only two terminating resistances 3. Check the short-circuits between the signals: - CAN_GND and CAN_L/ CAN_H, - between the CAN_SHLD (shielding) and CAN_L / CAN_H. 4. Check that all of the items of equipment are connected to the ONE local earth. NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

12.02.2015

58

12.02.2015

59

End of 2ndPart

NSC-F-FR/W.Gomolka

CoDeSys pbF and CANopen

20