CANopen Implementierung "nur" für Sensordaten

[Hendrik S. (shotar)]

Hallo,

um Analogwerte einer DMS-Messbrücke auszuwerten bekomme ich bald diesen 
Can-Bus A/D Wandler:
http://www.microcontrol.net/produkte/io-module/trs/1-x-druck-in/

Die Kommunikation läuft über eine Art Raspberry Pi (ARM A7 Prozessor mit 
Linux OS und integriertem CAN Port). Ich möchte allersings "nur" den 
Analogwert zyklisch (50 Hz) auslesen. Ich habe bisher keinerlei 
Erfahrung mit CANopen und möchte für dieses Projekt die Implementierung 
sehr einfach halten. Ich benötige die speziellen Heartbeat und 
Statusabfragen nicht die mit CANopen liefern könnte.

In der EDS Datei vom Hersteller finde ich folgende Einträge:
;--- 7100h: AI Field Value 16Bit ------------------------------------
[7100]
SubNumber=2
ParameterName=AI Field Value 16Bit
ObjectType=0x08

[7100sub0]
ParameterName=Number of entries
ObjectType=0x7
DataType=0x5
AccessType=ro
DefaultValue=0x1
PDOMapping=0

[7100sub1]
ParameterName=Channel 1
ObjectType=0x7
DataType=0x6
AccessType=ro
DefaultValue=0x00
PDOMapping=1


;--- 7130h: AI Process Value 16Bit ----------------------------------
[7130]
SubNumber=2
ParameterName=AI Process Value 16Bit
ObjectType=0x08

[7130sub0]
ParameterName=Number of entries
ObjectType=0x7
DataType=0x5
AccessType=ro
DefaultValue=0x1
PDOMapping=0

[7130sub1]
ParameterName=Channel 1
ObjectType=0x7
DataType=0x3
AccessType=ro
DefaultValue=0x00
PDOMapping=1





In meiner bisherigen Suche habe ich öfter gelesen, dass man die Daten 
einfacher über SDO auslesen kann. Warum?
http://stackoverflow.com/questions/1232624/how-to-program-a-simple-canopen-layer

Ich habe jetzt schon einige Handbücher und Foreneinträge gelesen, steige 
aber mit den PDO und SDO von CANopen nicht so richtig durch. Wie läuft 
so eine Kommunikation denn genau ab?

Wenn ich das richtig verstanden habe, dann sieht ein CANopen Telegramm 
so aus:

Identifier - DLC - DATA (byte0 - byte7)

wobei der Identifier mit den ersten 4 Bit den Service (zB 1100 für SDO 
lesen) und den restlichen 7 Bit die Node-ID festlegt. Aber wo genau 
finde ich denn den Analogwert wieder?

Ich stelle mir mein Programm im Moment so vor, dass ich eine fest 
definiertes Anfrage-Telegramm über CAN sende und im Anschluss die 
Antwort mit dem Analogwert erhalte. Ich nutze dabei SocketCAN unter 
Linux.

[Hendrik S. (shotar)]

Als "Vorlage" könnte ich mir dieses Projekt vorstellen:
https://www.raspberrypi.org/forums/viewtopic.php?p=444938

Hier wäre der Code-Teil für das CAN-Telegramm:

     struct can_frame frame_led;
     frame_led.can_id = 0x300 + NodeId;  // use all led 8 bit resolution 
TPDO output
     frame_led.can_dlc = 3;  // only 3 bytes  Red,Green and blue
     frame_led.data[0]=Red;
     frame_led.data[1]=Green;
     frame_led.data[2]=Blue;
     write(sfd,&frame_led,sizeof(struct can_frame));

[Volker S. (vloki)]

Deine Vorlage scheint aber für eine PDO zu sein.
Bei den PDOs bestimmt nur die ID den Inhalt und alle 8 möglichen 
Daten-Bytes können auch Daten enthalten.

Bei CANopen sind die IDs in feste Bereiche eingeteilt:

typedef enum{//:quint16{
    COBID_NMT       = 0x000,
    COBID_SYNC      = 0x080,
    COBID_TIMESTAMP = 0x100,
    COBID_EMERGENCY = 0x080,
                                    //Prozessdatenobjekte
    COBID_RXPDO1    = 0x180,        //RX Empfangs-PDO
    COBID_TXPDO1    = 0x200,        //TX Sende-PDO
    COBID_RXPDO2    = 0x280,
    COBID_TXPDO2    = 0x300,
    COBID_RXPDO3    = 0x380,
    COBID_TXPDO3    = 0x400,   // 00 04
    COBID_RXPDO4    = 0x480,   // 80 04
    COBID_TXPDO4    = 0x500,

    COBID_RXSDO     = 0x580,        //Servicedatenobjekte
    COBID_TXSDO     = 0x600,
    COBID_NMT_LNG   = 0x700         //NMT Network-Management(-Nachricht)
                                    //LNG Life-Node-Guarding
}CANOPEN_COBID;

Eine ID wird aus einer Basis und einer Bus ID gebildet.
Die Basis für SDO Anfragen von deinem Master wäre 0x600 + die ID des 
Sensors. Bei 3 Sensoren z.B. 0x601, 0x602, 0x603

Ein SDO Transfer zur Abfrage des Sensorwertes würde aus einem Request 
CO_REQ_SDO_RD und einer Response CO_RES_SDO_RD_x bestehen.

Bei SDOs sind die ersten 4 Bytes der Daten gar keine Daten, sondern 
Identifyer. Das erste wäre zum Beispiel der REQUEST, der Beschreibt, was 
für einen Zugriff gemacht werden soll. (Lesen, schreiben und wie viel 
Bytes)
Dann kommen zwei OBJECT-Bytes und ein SUBINDEX die praktisch die Adresse 
des Parameters (z.B. DMS Daten) angeben.


Einer von mir verwendete Nachrichten-Struktur sieht so aus:

typedef struct{
    CANOPEN_COBID   cobID;
    CANOPEN_RTF_DLC rtf_dlc;
    union{
        struct{
            CANOPEN_REQ     request;
            quint16         object;
            quint8          subindex;
            quint32         data_sdo;
        };
        struct{
            quint64         data_pdo;
        };
    };
}CANOPEN_MESSAGE

Für den Request gibt es zum Beispiel folgende Möglichkeiten:

typedef enum{//:quint8{
    CO_REQ_START_NODE   = 0x01,     //SDO Request, Starte Node
    CO_REQ_STOP_NODE    = 0x02,     //SDO Request, Stoppe Node
    CO_REQ_SDO_WR_4     = 0x23,     //SDO Request, 4 Byte schreiben
    CO_REQ_SDO_WR_2     = 0x2B,     //SDO Request, 2 Byte schreiben
    CO_REQ_SDO_WR_1     = 0x2F,     //SDO Request, 1 Byte schreiben
    CO_RES_PDO_RD       = 0x37,
    CO_REQ_SDO_RD       = 0x40,     //SDO Request, Leseanforderung
    CO_RES_SDO_RD_4     = 0x43,     //SDO Response auf Leseanforderung, 4 
    CO_RES_SDO_RD_2     = 0x4B,     //SDO Response auf Leseanforderung, 2 
    CO_RES_SDO_RD_1     = 0x4F,     //SDO Response auf Leseanforderung, 1 
    CO_RES_SDO_WR       = 0x60,     //SDO Response, Schreiben erfolgreich
    CO_RES_SDO_ABT      = 0x80,     //SDO Response, Fehler
    CO_REQ_RESET_NODE   = 0x81      //SDO Request, Neustart der FW, }CANOPEN_REQ;

Für den Sensor sähe das ungefähr folgendermaßen aus

Message.COB_ID = 0x600 + SENSOR_ID; // (0x600 für SDO)
Message.rtf_dlc = 4;   // request, object, subindex
Message.request = CO_REQ_SDO_RD;
Message.object = 0x7130;
Message.subindex = ? (keine Ahnung, 0?)

bei der Antwort wäre die
ID -> 0x580 + SENSOR_ID
dlc -> 6 // request, object, subindex, + 2? Bytes für 16bit Daten
request -> CO_RES_SDO_RD_2
object -> 0x7130
subindex -> 0
data_sdo -> der Messwert

[Hendrik S. (shotar)]

Vielen Dank. Aber worin besteht denn der Unterschied die Daten per SDO 
oder PDU abzufragen?

Ich habe nun aus dem Raspberry und deinem Code etwas zusammengebastelt:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdint.h>

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/uio.h>
#include <net/if.h>

#include <linux/can.h>
#include <linux/can/raw.h>

#define node_id 127;

typedef enum{
    COBID_NMT       = 0x000,
    COBID_SYNC      = 0x080,
    COBID_TIMESTAMP = 0x100,
    COBID_EMERGENCY = 0x080,
                                    //Prozessdatenobjekte
    COBID_RXPDO1    = 0x180,        //RX Empfangs-PDO
    COBID_TXPDO1    = 0x200,        //TX Sende-PDO
    COBID_RXPDO2    = 0x280,
    COBID_TXPDO2    = 0x300,

    COBID_RXSDO     = 0x580,        //Servicedatenobjekte
    COBID_TXSDO     = 0x600,
    COBID_NMT_LNG   = 0x700         
}CANOPEN_COBID;

typedef enum{
  CMD_TX = 0x22,
  CMD_TX_4 = 0x23,
  CMD_TX_3 = 0x27,
  CMD_TX_2 = 0x2B,
  CMD_TX_1 = 0x2F,
  CMD_RX = 0x40,
  CMD_RX_1 = 0x40,
  CMD_RX_2 = 0x40,
  CMD_RX_3 = 0x40,
  CMD_RX_4 = 0x40
}CANOPEN_CMD;

struct CANopen_message{
  CANOPEN_COBID id;
  uint8_t dlc;
  CANOPEN_CMD cmd;
  uint16_t index;
  uint8_t subindex;
  char data[4];
};

int main (int argc, char * argv[])
{
  struct sockaddr_can addr;
    struct ifreq ifr;
    int sfd, ai_val;

    // open part SocketCAN
    sfd = socket(PF_CAN, SOCK_RAW, CAN_RAW);
    if(sfd<0){
        perror("socket : ");
        return -1;
    }

    strcpy(ifr.ifr_name, "can0"); // "can0" is the name of the CAN network interface
    ioctl(sfd, SIOCGIFINDEX, &ifr);

    addr.can_family = AF_CAN;
    addr.can_ifindex = ifr.ifr_ifindex;

    // Bind the socket
    if(bind(sfd, (struct sockaddr *)&addr, sizeof(addr))<0){
         perror("bind: ");
         close(sfd);
         return -1;
    }

    // send SDO message for AI value
    struct CANopen_message message;
    message.id = COBID_TXSDO + node_id;      // SDO-Rx + Node ID
    message.dlc = 4;         // length
    message.cmd =  CMD_RX;   // read, length unknown
    message.index = 0x7130;  // index for AI Process Value 16Bit
    message.subindex = 0x01; // Channel 1
    write(sfd,&message,sizeof(struct CANopen_message));

    // receive SDO message
    read(sfd,&message,sizeof(struct CANopen_message));
    ai_val = (int) (message.data[0] + message.data[1]);
    printf("Messwert: %d\n", ai_val);
    close(sfd);
    return 0;
}

Ich kann das Programm leider noch nicht testen, da ich den Sensor erst 
in 2 Wochen bekomme. Da ich auch in C-Programmierung noch recht 
unerfahren bin, bin ich für jegliches Feedback dankbar :)

[Volker S. (vloki)]

Die PDOs werden automatisch in gewissen Zeitabständen geschickt.
(nachdem man das so konfiguriert hat)

Es gibt keine Requests, Index/Subindex. Die Daten beginnen sofort.
Anhand der PDO Nr. weiß man um welche Daten es sich handelt.

Wenn der DMS Messwert auf PDO1 gemappt ist und der Sensor die Busadresse 
1 hat, dann bekommt man in regelmäßigen Zeitabständen automatisch die 
Nachricht

id -> 0x181
dlc -> 2
daten -> 16bit Messwert

[Steffen R. (steffen_rose)]

Hendrik S. schrieb:
> Aber worin besteht denn der Unterschied die Daten per SDO
> oder PDU abzufragen?

SDO - Service Data Object :
- Ist ein bestätigter Dienst. Du erhälst eine Bestätigung, ob der Wert 
übernommen wurde, gültig ist oder der Wert überhaupt existiert.
- Kann für beliebige Einträge im Objektverzeichnis entsprechend der 
Zugriffsrechte genutzt werden.
- Es gehen auch Daten größer 8 Byte.
- Es wird ein Gerät direkt angesprochen.
- Wird häufig zur Konfiguration genutzt.

PDO - Process Data Objekt :
- Wird für Echtzeitdaten genutzt.
- Es kommt auf das Mapping der PDOs ab, welche Daten übertragen werden. 
Diese sind nicht beliebig.
- max. 8 Byte
- mehrere Objekte (Werte) gleichzeitig möglich, solange die 8 Byte nicht 
überschritten werden.
- Es gibt verschiedene Events, die das Senden/Empfangen der PDOs steuern 
können.
- PDOs müssen konfiguriert werden
- PDOs gehen nur im NMT Operational State
- PDOs ist Broadcast Dienst, d.h. es kann mehrere Empfänger geben.

(Man verzeihe mir, das einiges etwas lax fomuliert ist.)

[Steffen R. (steffen_rose)]

http://www.can-cia.org/standardization/specifications/#

Der Standard CiA 301 beschreibt die Kommunikation. Du must dich 
registrieren, ansonsten ist der Download aber kostenfrei.

Der Standard ist weniger zum Lernen geeignet. Aber wenn es um Details 
geht gut zum Nachschlagen. Wer CANopen macht, sollte ihn liegen haben.

[Hendrik S. (shotar)]

wäre ja auch nicht schlecht. So eine Einstellung macht man am besten 
über einen CANopen Manager am PC? Ich habe mir den Kickdrive Zero dazu 
installiert und die EDS Datei eingelesen.

[Steffen R. (steffen_rose)]

Hendrik S. schrieb:
> So eine Einstellung macht man

Wenn der Sensor das Speichern der Konfiguration erlaubt, kann man diese 
am PC erstellen, runterschaffen und speichern. Manchmal kann man die 
Geräte auch Selbststartend konfigurieren, d.h. sie gehen eigenständig 
nach NMT Operational.

Hierfür muß man in die Gerätebeschreibung sehen oder den Hersteller 
befragen.

Wenn man sich auskennt, kann man es auch einfach ausprobieren. Als 
Anfänger ist man aber häufig am zweifeln, ob man alles richtig gemacht 
hat.

[Hendrik S. (shotar)]

Steffen R. schrieb:
> Wenn der Sensor das Speichern der Konfiguration erlaubt, kann man diese
> am PC erstellen, runterschaffen und speichern. Manchmal kann man die
> Geräte auch Selbststartend konfigurieren, d.h. sie gehen eigenständig
> nach NMT Operational.

Ja,  die "NMT Startup" Konfiguration gibt es für die MicroControl 
A/D-Wandler. Dazu gibt es auch den "PDO Event Timer", der wohl für 
meinen Zweck richtig wäre.

Zur Konfiguration kann ich mich dann einfach mit einem USB/CAN-Adapter 
mit dem Gerät verbinden und die entsprechenden Parameter anpassen. Ich 
habe als Freeware CANopen Programm bis jetzt nur den Kickdrive Zero
http://www.kickdrive.de/en/index.html?products_kickdrive_zero.htm
gefunden. Gibt es da auch etwas für Linux?

[Volker S. (vloki)]

Hast du denn schon einen USB/CAN Adapter?
Du kannst doch die Konfiguration direkt von deiner "Art Raspberry" aus 
durchführen. Dazu müssen nur die entsprechenden Objekte (über SDO) 
richtig beschrieben werden.
Die Kommunikation musst du doch eh programmieren. Die ersten Schritte 
kannst du ja über die SDOs machen. Wenn du das drauf hast, dann ist die 
Konfiguration kein Problem mehr...

[Steffen R. (steffen_rose)]

Hendrik S. schrieb:
> Zur Konfiguration kann ich mich dann einfach mit einem USB/CAN-Adapter
> mit dem Gerät verbinden

Die API ist nicht standardisiert. Insofern müßtest Du schauen, welchen 
CAN Adapter du nutzen möchtest.

Unter Linux ist die socketCAN API weit verbreitet und Teil des Kernels.

[Hendrik S. (shotar)]

Volker S. schrieb:
> Hast du denn schon einen USB/CAN Adapter?
ich habe mir gestern den USBtin von Thomas Fischl bestellt:
http://www.fischl.de/usbtin/

Volker S. schrieb:
> Du kannst doch die Konfiguration direkt von deiner "Art Raspberry" aus
> durchführen. Dazu müssen nur die entsprechenden Objekte (über SDO)
> richtig beschrieben werden.
> Die Kommunikation musst du doch eh programmieren. Die ersten Schritte
> kannst du ja über die SDOs machen. Wenn du das drauf hast, dann ist die
> Konfiguration kein Problem mehr...
Naja, wenn ich den Sensor vorher am PC so einstelle, dass er zyklisch 
die Daten per PDO sendet, brauch ich ja auf dem Raspberry nur noch den 
entsprechenden Teil der CAN Message auswerten. Wäre vielleicht etwas 
"eleganter".

Steffen R. schrieb:
> Unter Linux ist die socketCAN API weit verbreitet und Teil des Kernels.
Ja die socketCAN unter Linux kenn ich, aber das ist ja kein CANopen 
Manager mit dem ich ESD Dateien direkt einlesen kann. Aber mit dem 
Windows Tool von Kickdrive werde ich wohl auch zurecht kommen.

[Volker S. (vloki)]

Hendrik S. schrieb:
> Volker S. schrieb:
>> Hast du denn schon einen USB/CAN Adapter?
> ich habe mir gestern den USBtin von Thomas Fischl bestellt:
> http://www.fischl.de/usbtin/

Na dann hast du ja auch PC Software, welche du verwenden kannst...

[Steffen R. (steffen_rose)]

Hendrik S. schrieb:
> Ja die socketCAN unter Linux kenn ich, aber das ist ja kein CANopen
> Manager mit dem ich ESD Dateien direkt einlesen kann.

Da aber nicht jedes Tool alle Interfaces unterstützt, ist die 
Entscheidung für eine API (socketCAN, can4linux usw.) relevant.

Freie CANopen Master Tools kenne ich nicht. Und ein freier CANopen 
Master Stack hilft Dir ja nicht weiter.