Introduction

The CANBus channels, which Robox controllers are equipped with, have the DS301, DS401 and DS402 protocols and are capable of controlling up to a maximum of 16 devices per channel. Up to 4 PDOs are supported in transmission and 4 PDOs in reception. The RTE firmware can manage up to a maximum of 4 CANBus channels as masters, thus totaling 64 devices.

For CANBus channel management using CAN.INT boards, the CANBus communication manager (CODMvvrr.UFW file) must be present on the system partition of the flashcard(SYS_DIR).

The file containing the network configuration COCn.CFG must be present (It must be in the CAN_DIR or USER_DIR folder alias).

Bookmarks

Related arguments

Configuration

COCn.CFG file

The COCn.CFG file contains the configuration of a CANBus network channel; there can be up to 4 channels (maximum number).

n represents the channel number (0-:-3), so COC0.CFG contains the configuration of the first channel, then come COC1.CFG for the second channel, COC2.CFG and finally COC3.CFG.

These are ASCII files that are assumed by RTE only when the control is turned on and are used both to parameterize the network and to learn about the data packets exchanged with each device present.

To generate these files, the RDE development environment provides the user with a special configurator (see documentation on the CANopen configuration editor). Through the latter it is possible to configure the parameters related to the CANBus communication channel (bit rate, sync frequency, etc... ), furthermore for each individual WS in the network the user can program which Robox variables should be involved in the CAN communication, mapping them in the RX and TX PDOs.

NOTE: Make sure that in the project window--> properties--> configuration--> canopen there is a flag on enable. In this case each generation will automatically link the generated cfg file in the project window tab "flash file".

Steps to follow to configure the network

The steps for the user to follow are:

•Create the COC file related to the channel that describes how many and what devices are present on the line. From the main menu select file--> new, choose the type "coc" and assign the name of the can line (suggestion "coc")

•From the CANOpen configuration editor window proceed to channel parameterization and description of connected nodes

•From the main menu select edit--> file generation then select 0 for CAN1 channel, 1 for CAN2 channel etc.

NOTE: The channel number and associated cfg extension will be added to the file name. This file will need to be uploaded to the CF and will be used by RTE at power up to analyze/configure the network.

•Tracking the COC file to the graphical project configurator (settings--> CANOpen)

The CANOpen configuration window will request:

•Node ID : Represents the physical number of the CAN node and can be varied (1-:-127)

•Robox station ID : Represents the number of the logical can Robox workstation (1-:-64)

In the project configuration window--> axis menu is requested:

•Axis ID : Logical Robox axis referenced by predefined variables (IP, CP etc) (1-:-32)

•Robox station ID : Represents the number of the workstation can logical Robox (1-:-64)

•Robox station ID MUST be set by the user equal in the two windows

NOTE: This double association is necessary since RTE manages up to 4 separate can networks. So there can be two equal node IDs but on different networks that clearly must be associated with two different Robox station IDs!

PDO Mapping

In PDOs in RX I can map the following types:

•Real position (CP(ax))

•Drive ideal position (Drive ideal position)

•Input word (IW(n))

•CANOpen status word

•Integer 16 register (R(n) for 16 bit Robox controls)

•Integer 32 register (R(n) for 32-bit Robox controls)

•Real register (RR(n))

•Auxiliary (It is used only by the operating system to execute the 0 loop, mapping it into PDOs allows the drive to speed up the communication of micro reached. The variable is not visible to the user)

•Input Word + auxiliary 0 (This is the same as the previous one, but the state of the auxiliary is mapped to an IW(n) so that the user can see its value)

In PDOs in TX I can map the following types:

•Ideal position (IP(ax))

•Ideal speed (IV(ax))

•Output Word (OW(n))

•Speed Reference (SREF(ax))

•Torque Reference (TREF(ax))

•CANOpen control word

•Integer 16 register (R(n) for 16-bit Robox controls)

•Integer 32 register (R(n) for 32-bit Robox controls)

•Real register (RR(n))

•Auxiliary (Used to speed up the command for C0 execution)

NOTE: If properly programmed, the COCn.CFG file can help in diagnosing the application by enabling and disabling errors or warnings, returned by the system, that may make debugging the application cumbersome.

Operations performed by the master when starting the network

The operations performed by the Robox CAN master when starting a CAN network are as follows:

•First sends an NMT broadcast message of ENTER_PRE_OPERATIONAL to put all possible slave nodes present in PRE-OP

•Checks for the presence of mapped slaves in the network by asking for the DeviceType object (0x1000 0x00)

a.If there is no response or the response value is different from what it expects it aborts the configuration of that node

b.If there is response with correct value (or wrong value but ignore DeviceType value flag) continues

•Sends the CommunicationCyclePeriod object (0x1006 0x00)

c.If there is no response or wrong response (without bypass flag) aborts the configuration of that node

d.If there is ok response (or bypass flag) it continues

•Configures the WATCH-DOG CANOpen protocol set for that node. The operations performed depend on the protocol configured

e.HEARTBEAT: sends the ProducerHeartbeatTime object (0x1017 0x00)

i.If there is no response or wrong response (without bypass flag) aborts the configuration of that node

ii.If there is ok response (or bypass flag) it continues

f.LIFEGUARD: sends the GuardTime (0x100C 0x00), LifeTimeFactor (0x100D 0x00) objects and sets the ProducerHeartbeatTime (0x1017 0x00) object to 0 (by default for CANopen specification HEARTBEAT is used, if ProducerHeartbeatTime = 0 LIFEGUARD is activated)

i.If there is no response or wrong response (without bypass flag) aborts the configuration of that node

ii.If there is ok response (or bypass flag) it continues

•Configures the PDOs as specified in the node configuration

g.If there is no answer or wrong answer (without bypass flag) aborts the configuration of that node

h.If there is ok response (or bypass flag) it continues

•First sends a START NMT broadcast message to put all possible slave nodes present in OPERATIONAL

•It begins broadcasting the mapped TxPDOs and the SYNC and expects to receive the mapped RxPDOs

NOTE: Since RTE 34.30.2, the ability to change the LIFEGUARD protocol parameter configuration sequence has been added. Setting the value of Device Type with bit 30 to 1 (0x40000000) will change the sequence of sending parameters: first the HEARTBEAT time will be reset, then the LIFE_GUARD_TIME and LIFE_GUARD_FACTOR will be configured. The other bits of the Device Type remain unchanged and must match the value of the DEVICE_TYPE object (0x1000).

Operations performed when a node is disconnected

The Robox CAN master uses the configured WATCH-DOG protocol to check that a node is still present and, if necessary, to verify that it has disappeared from the network. Without a configured WATCH-DOG protocol, the Robox CAN master cannot verify the presence of a node.

If a station disappears during runtime, if the appropriate flag is specified on the individual station, the Robox CAN master requests the DeviceType from the node via sdo every 2.5s, when it gets a correct answer it repeats the operations performed at startup from step 1 to step 6 (see previous chapter) but sending NMT messages only to that node and not to all via broadcast.

Functions/Instructions

Keywords

SHELL commands

Device commands