6.0.1 • Published 1 month ago

canopen v6.0.1

Weekly downloads
69
License
MIT
Repository
github
Last release
1 month ago

node-canopen

CANopen is the internationally standardized (EN 50325-4) CAN-based higher-layer protocol for embedded control system. More information on CANopen can be found on the CiA site

This library allows the manipulation of CANopen devices as defined in CiA 301.

Porting Guide (Version 5 -> 6)

When updating from version 5 to version 6 be aware of the following changes:

  1. Modifying the Eds via the protocol modules has been deprecated and the preferred method is to use the new dedicated methods in the Eds class itself. This change was made to allow configuration without needing to create a Device object first. The following table is non-exhaustive and serves only to illustrate the change:

    Old methodNew method
    device.emcy.cobId = 0x8Adevice.eds.setEmcyCobId(0x8A)
    device.nmt.producerTime = 500device.eds.setHeartbeatProducerTime(500)
    device.sdo.addServer(0x8B)device.eds.addSdoClientParameter(0x8B)
    device.sync.generate = truedevice.eds.setSyncGenerationEnable(true)
  2. NMT state now matters. Prior to version 6 the NMT state was available, but not used internally. The Device object is now aware of the NMT state and will bring up and shutdown protocol objects as the state changes. If your PDOs are not firing after the update make sure you are calling Nmt#startNode to switch to NmtState.OPERATIONAL. This new behavior should only take effect upon calling Device#start().

  3. Events have been refactored and moved to their respective protocol modules. Old events are still available, but will only fire if the Device#init() method has been called.

  4. The internal Eds array of DataObjects is now keyed from the hex index rather than the decimal index to make debug printing less confusing. A getter with the old indexing is provided so that iterating directly on Eds.dataObjects will still work as expected, however you should switch to using the new iterator methods (Eds.values(), Eds.entries(), Eds.keys()).

  5. SDO client/server parameters will no longer assume you want to add the node ID if you choose 0x580/0x600 for the SDO COB-IDs. As far as I can tell this is not officially in the standard, but was a convienence added to some other libraries.

Documentation

Pre-built documentation for the latest release is available here.

Examples for each protocol are also available in the examples folder.

Device

The Device class represents a CANopen device and provides context for the protocol objects as well as access methods for the manufacturer data fields. It contains the Eds and protocol objects.

OD EntryDescriptionSupported
0x1000Device type:x:
0x1002Manufacturer status register:heavy_check_mark:
0x1008Manufacturer device name:heavy_check_mark:
0x1009Manufacturer hardware version:heavy_check_mark:
0x100AManufacturer software version:heavy_check_mark:
0x1010Store parameters:x:
0x1011Restore default parameters:x:

Eds

The Eds class represents a CANopen electronic datasheet file and can be used to load and save the eds file format as defined in CiA 306. Device configuration files (DCF) are not currently supported.

Eds provides setters for many of the communication profile objects that are defined in CiA 301. Most of the protocol objects require one or more entries in the Eds before they can function. Typically the user will want to create or set those entries before calling Device.start().

Protocols

Emergency - EMCY

The CANopen emergency protocol is used to indicate internal errors with a CANopen device. Call Emcy.write() to produce an emergency object. If a valid 'Emergency consumer object entry' is present, the Emcy module will emit event:emergency when the matching COB-ID is consumed.

OD EntryDescriptionSupported
0x1001Error register:heavy_check_mark:
0x1003Pre-defined error field:heavy_check_mark:
0x1014COB_ID EMCY:heavy_check_mark:
0x1015Inhibit time EMCY:heavy_check_mark:
0x1028Emergency consumer object:heavy_check_mark:
0x1029Error behavior object:x:

Layer Setting Services - LSS

The CANopen layer setting services protocol allows the CAN-ID and bitrate of an LSS consumer device to be modified. This allows for setting up a network of identical devices without relying on physical dip switches or non-volatile storage to distinguish between them.

OD EntryDescriptionSupported
0x1018Identity object:heavy_check_mark:

Supported Features:

  • LSS producer :heavy_check_mark:
  • LSS consumer :heavy_check_mark:

Network Management - NMT

The CANopen network management protocol is used to manipulate the state of NMT consumer devices on the network and is responsible for the device heartbeat. Heartbeat generation will begin automatically when 'Producer heartbeat time' is set. If a 'Consumer heartbeat time' entry is present, then the Nmt module will emit event:timeout if the consumer heartbeat is lost.

OD EntryDescriptionSupported
0x100CGuard time:x:
0x100DLife time factor:x:
0x1016Consumer heartbeat time:heavy_check_mark:
0x1017Producer heartbeat time:heavy_check_mark:

Supported Features:

  • Remote state changes :heavy_check_mark:
  • Heartbeat
    • Generation :heavy_check_mark:
    • Monitoring :heavy_check_mark:
  • Command processing
    • State changes :heavy_check_mark:
    • Reset node :heavy_check_mark:
    • Reset communications :heavy_check_mark:

Process Data Object - PDO

The CANopen process data object protocol is used for broadcasting data changes with minimal overhead, similar to a more traditional CAN network architecture. A mapped TPDO can be sent with the Pdo.write() method. Event driven TPDOs will be sent automatically when the device is in NmtState.OPERATIONAL. The Pdo module will emit event:pdo when a mapped RPDO is consumed.

OD EntryDescriptionSupported
0x1400 - 0x15FFRPDO communication parameter:heavy_check_mark:
0x1600 - 0x17FFRPDO mapping parameter:heavy_check_mark:
0x1800 - 0x19FFTPDO communication parameter:heavy_check_mark:
0x1A00 - 0x1BFFTPDO mapping parameter:heavy_check_mark:

Service Data Object - SDO

The CANopen service data object protocol provides direct access to a device's object dictionary. Call the SdoClient.upload() or SdoClient.download() methods to initate a transfer.

OD EntryDescriptionSupported
0x1200 - 0x127FSDO server parameter:heavy_check_mark:
0x1280 - 0x12FFSDO client parameter:heavy_check_mark:

Synchronization - SYNC

The CANopen sync protocol is used to synchronize actions between devices on the network. If enabled, Sync message generation will begin automatically when Device.start() is called. Sync will emit event:sync when a Sync object is consumed.

OD EntryDescriptionSupported
0x1005COB-ID SYNC:heavy_check_mark:
0x1006Communication cycle period:heavy_check_mark:
0x1007Sync window length:x:
0x1019Sync counter overflow value:heavy_check_mark:

Time stamp - TIME

The CANopen time protocol is used to provide a simple network clock. Call Time.write() to produce a time stamp object. Time will emit event:time when a time stamp object is consumed.

OD EntryDescriptionSupported
0x1012COB-ID TIME:heavy_check_mark:
0x1013High resolution time stamp:x:
6.0.1

1 month ago

6.0.0

3 months ago

6.0.0-dev

3 months ago

5.1.0

6 months ago

5.0.9

1 year ago

5.0.8

2 years ago

5.0.7

2 years ago

5.0.6

2 years ago

5.0.5

2 years ago

4.0.1

2 years ago

4.0.0

2 years ago

5.0.4

2 years ago

5.0.3

2 years ago

5.0.2

2 years ago

5.0.0

2 years ago

3.1.5

2 years ago

3.1.4

3 years ago

3.1.3

3 years ago

3.1.2

3 years ago

3.1.1

3 years ago

3.1.0

3 years ago

3.0.1

3 years ago

3.0.0

3 years ago

2.8.2

3 years ago

2.8.1

3 years ago

2.8.0

3 years ago

2.7.4

3 years ago

2.7.2

3 years ago

2.7.3

3 years ago

2.7.1-beta

3 years ago

2.7.0-beta

3 years ago

2.6.0-beta

3 years ago

2.5.4-beta

3 years ago

2.5.3-beta

3 years ago

2.5.2-beta

3 years ago

2.5.1-beta

4 years ago

2.5.0-beta

4 years ago

2.4.0-beta

4 years ago

1.4.7

4 years ago

1.4.6

4 years ago

1.4.5

4 years ago

2.2.3-beta

4 years ago

2.2.2-beta

4 years ago

2.2.1-beta

4 years ago

2.2.0-beta

4 years ago

2.1.8-beta

4 years ago

2.1.7-beta

4 years ago

2.1.6-beta

4 years ago

2.1.5-beta

4 years ago

2.1.4-beta

4 years ago

2.1.3-beta

4 years ago

2.1.2-beta

4 years ago

2.1.1-beta

4 years ago

2.1.0-beta

4 years ago

2.0.0-beta

4 years ago

1.4.4

4 years ago

1.4.3

4 years ago

1.4.2

4 years ago

1.4.1-beta

5 years ago

1.4.0-beta

5 years ago

1.3.7

5 years ago

1.3.6

5 years ago

1.4.0

5 years ago

1.3.4

5 years ago

1.3.3

5 years ago

1.3.2

5 years ago

1.3.0

5 years ago

1.2.1

6 years ago

1.2.0

6 years ago

1.1.1

6 years ago

1.1.0

6 years ago

1.0.1

6 years ago

1.0.0

6 years ago