CANdb-Unterstützung für bestimmte Terminal-Varianten

(Achtung: nicht für alle Terminals geeignet - siehe Feature Matrix)

Übersicht

Einleitung
Prinzipieller Ablauf
Optionen und Konfigurationsmöglichkeiten
Senden von CAN-Telegrammen (mit per Datenbank definierten Signalen)
1. Beispiel zum Senden von 'CANdb'-Signalen
Anhang
1. Strategie zur Belegung von CAN-Message-Objekten (bei alten Geräten mit 'FULL-CAN'-Controller)
2. Warenzeichen, Haftungsausschluß
3. Letzte Änderungen

Weitere Informationen:

Importieren von CAN/CAN FD Signal- und PDU-Definitionen aus AUTOSAR XML
Handbuch des Programmiertools (nicht CANdb-spezifisch)
Display-Variablen (allgemein, nicht CANdb-spezifisch)
Frequently Asked Questions ('oft' gestellte Fragen)
Die Feature Matrix - zeigt welche MKT-Terminals für CANdb-Konfiguration geeignet sind

Hinweis: Änderungen und Aktualisierungen des Hilfesystems werden immer erst am englischsprachigen "Master" vorgenommen, und dann -beizeiten- in andere Sprachen übersetzt.

1. Einleitung

In diesem Dokument steht "CANdb" für CANdb Network Files. Eine CANdb-Datei (*.DBC) dient zum Speichern von Informationen über ein ganzes CAN-Netzwerk (ein großer Unterschied zu CANopen !). CANdb ist eingetragenes Warenzeichen von Vektor Informatik (oder Vector Cantech, Inc. ?).

Das Programmiertool kann nur eine kleine Untermenge der Informationen verarbeiten, die in einer CANdb-Datei enthalten sein könnten.

Das CAN-Anzeige-Terminal unterstützt derzeit :

CAN-Signale mit 1..32 bit, die per CAN-Bus als SIGNED oder UNSIGNED INTEGER übertragen werden
CAN-Signale mit 32 oder 64 bit, die per CAN-Bus als FLIESSKOMMA-WERT übertragen werden
Multiplexersignale und gemultiplexte Signals (früher auch "Mode-Signale" und "Mode-abhängige Signale" genannt)
Motorola oder Intel - Byte-Reihenfolge (allerdings nicht der Krampf mit "Motorola vorwärts und rückwärts")
Umrechnung mit Faktor und Offset aus dem "raw-signal-format" in eine Fließkommazahl für die Anzeige

Nicht unterstützt vom CAN-Anzeige-Terminal oder/und dem Programmiertool:

Fliesskomma-Werte in CAN-Telegrammen die nicht dem 32- oder 64-Bit "IEEE-Format" entsprechen
Integer-Werte mit mehr als 32 bit im "Signal"
"Enumeration values" mit Zeichenketten
andere "Attribute" in der CANdb-Datei

Das "Anzeige-Terminal mit CAN-Signal-Verarbeitung" ist eine spezielle Variante von MKT's UPT (User Programmable Terminal), welches intern nur mit 'Variablen' arbeitet. Einige dieser anwenderdefinierten Variablen können mit 'Signalen' (a la CANdb) verbunden sein, während andere Variablen nicht per Kommunikationskanal mit der "Außenwelt" verbunden sind. Variablen, die nicht per Kommunikationskanal verbunden sind, dienen "lokal" zur Aufnahme von berechneten Werten, Merkern, Meldungen, etc.

Eine Display-Variable kann einen Integer- oder Fliesskommawert enthalten. Falls eine Variable mit einem (CANdb-)Signal verbunden ist, findet oft noch eine Umwandlung aus dem per CAN übertragenen 'Rohwert' (i.A. Integer) in einen Fliesskommawert statt (als letzter Schritt vor der Anzeige auf dem Display).

Den Datentyp des Signals (bei der Übertragung per CAN) wird auf der Registerkarte 'CAN' im Programmiertool angezeigt, der Datentyp der daraus erzeugten Variablen steht auf der Registerkarte 'Variablen'. Das folgende Kapitel erläutert den Zusammenhang, und den prinzipiellen Ablauf zum Importieren von CAN-Signal-Definitionen aus einer Datenbank (*.dbc aka 'CANdb').

zurück zur Übersicht

Prinzipieller Ablauf zur Erstellung eines Anzeigeprogramms mit "CAN-Signalen"

Die folgenden Schritte sind erforderlich, wenn Sie CANdb-"Signale" (d.h. Signale die in einer DBC-Datei beschrieben sind) in Ihrer Terminal-Anwendung nutzen wollen:

Signal-Definitionen aus einer CANdb-Datei importieren
(auf der Registerkarte "CANdb")

⇓

Kontrollieren und Auswahl einiger CAN-Signaldefinitionen
(auf der Registerkarte "CANdb")

⇓

Signaldefinitionen in Anzeige-Variablen übertragen
(Umschaltung "CANdb" -> "VARIABLEN")

⇓

Entwickeln und Testen der Terminal-Programmierung
(auf diversen Registerkarten des Programmiertools)

⇓

Runterladen des Programms in ein "echtes" Terminal
(per CAN, Speicherkarte, Web-Server, etc)

Um Signaldefinitionen aus einer DBC-Datei zu laden, schalten Sie zunächst auf die Registerkarte "CANdb" im Programmiertool (für 'CANdb'-Terminals) um.

Importieren Sie Signaldefinitionen mit den Buttons "Load DBC #1" (für den ersten CAN-Bus) und "Load DBC #2" (für den zweiten CAN-Bus).

Die Signaldefinitionen werden in eine Definitionstabelle übernommen (s.U.).

Um Signale für die Steuerung des Terminalprogramms nutzen zu können, müssen Sie einen eindeutigen Variablennamen für jedes verwendete Signal bereitstellen. Dies ist sofort nach dem Import der *.dbc-Datei, aber auch später beim Erstellen der Anzeigeseiten möglich. Im Folgenden wird die erste Methode beschrieben (d.h. nach dem Import erst die 'interessanten' Signale in Variablen umwandeln, und danach die Variablen mit den Anzeigeelementen verknüpfen).
Im Gegensatz zu einem CAN-Signal-Namen muss ein Variablenname immer mit einem Großbuchstaben beginnen, und er darf maximal 8 Buchstaben umfassen (Ziffern an Position 2..8 sind zulässig) !

Sie können den Variablennamen entweder in der entsprechenden Tabellenspalte eingeben, oder -durch Doppelklick in die Tabelle- einen Variablenamen automatisch aus dem CANdb signal namen erzeugen lassen.

Nach der Definition geeigneter Variablennamem für alle benötigten Signale können Sie diese auf die Registerkarte "Variablen" übertragen (die Registerkarte "Variablen" existierte schon lange vor dem Einbau der "CANdb"-Funktionalität und kann aus Kompatibilitätsgründen nicht geändert werden).

Klicken Sie zu diesem Zweck auf den Button "Ready, transfer to Variables".

Nun können Sie die neu definierten Variablen in Ihrere Anwendung wie alle anderen Variablen verwenden (egal ob sie an einen SDO-, PDO-, CANdb- Kanal gekoppelt sind oder gar nicht mit der "Außenwelt" in Verbindung stehen).

Die folgenden Unterkapitel erläutern die Vorgehensweise zum Import von CAN-Signal-Definitionen noch genauer.

zurück zur Übersicht

Import von Signaldefinitionen aus einer DBC-Datei (CANdb network file)

nächster Schritt >>

Um Signaldefinitionen aus einer DBC-Datei zu importieren, schalten Sie zunächst auf die Registerkarte "CANdb" im Hauptfenster des Programmiertools um.

Falls dort "alte" Signaldefinitionen stehen, die Sie nicht länger brauchen, klicken Sie auf Menü ... Lösche die ganze Tabelle bevor Sie ein oder mehrere DBC-Dateien importieren (siehe auch Hinweis am Ende dieses Abschnitts: Sie können beim Import auch die alten Definitionen ersetzen lassen, ohne die Tabelle vorher zu löschen. So bleiben auch bereits vorhandene Verknüpfungen zwischen CAN-Signalen und Display-Variablen erhalten).

Für einen bestimmten Anwender war es nötig, die NODE- und MESSAGE-Namen beim Vergleich alter/neuer Signaldefinitionen zu ignorieren. Normalerweise wird eine Signaldefinition nur dann überschrieben, wenn sowohl NODE+MESSAGE+SIGNAL-Namen übereinstimmen. Um dieses Verhalten zu ändern, klicken Sie auf die Schaltfläche "Menu" und wählen "Optionen für CANdb-Datei-Import". Details über die Optionen zum Einlesen von CAN-Datenbanken options finden Sie in einem anderen Kapitel.

Verwenden Sie nun die Buttons "Load DBC #1" und "Load DBC #2" um einige CANdb-Dateien zu importieren.
"Load DBC #1" importiert die CANdb-Datei für den ersten CAN-Bus (Anschlußstecker "CAN 1" oder ähnlich).
"Load DBC #2" importiert die CANdb-Datei für den zweiten CAN-Bus (Stecker "CAN 2", falls vorhanden).

Hinweise:: Der Button "Lade andere..." dient zum Import von CAN-Datenbanken für andere Bussysteme (geplant z.B. Ethernet). Für Ethernet / UDP entfällt die CAN / CAN FD-spezifische Längenbegrenzung von 8 bzw. 64 Bytes pro Telegramm. Die Schnittstellen "CAN3" und "CAN4" sind für CAN-via-UDP reserviert. Mit der Funktion 'Datenbank für ALLE CAN-Busse laden' wird eine Datenbank so importiert, dass die Bus-Nummer für die Decodierung ignoriert wird. (eine empfangene Message wird dann gleichermaßen decodiert, unabhängig davon ob sie auf "CAN1", "CAN2", "CAN3" oder "CAN4" empfangen wurde. Diese Funktion steht nur bei Geräten mit einer aktuellen Firmware ab 11/2021 zur Verfügung - siehe auch: Dummy-CAN-Bus-Nummer cCanBusAny in der Script-Sprache).

Einige Varianten des Programmiertools bieten neben dem Import von DBC-Dateien (Database for CAN) auch den Import von AUTOSAR XML (*.arxml). Aufgrund der Komplexität und Varianten-/Versionsvielfalt von AUTOSAR kann leider nicht garantiert werden, das alle *.arxml-Dateien vom Programmiertool importiert werden können. Details zum Import bzw. zur Auswahl von Signalen für Bussysteme mit CAN, CAN FD, oder Ethernet aus AUTOSAR-Datenbanken finden Sie in zukünftigen Versionen des Programmiertools in einem separaten Dokument.

Die Signaldefinitionen werden in der folgenden Tabelle angezeigt:

Importierte CAN-Datenbank mit dem alten "Drei-Listen-Selektor"

Hinweis: Die Spalte VarName (Variablen-Name) wird direkt nach dem Importieren der CANdb-Dateien noch leer sein !

Auf der rechten Seite der CANdb-Import-Seite können Sie einen einzelnen Knoten (node), ein Telegramm (bzw Nachricht, message) aus dem Knoten, und ein Signal aus dem selektierten Telegramm auswählen. Dazu dienen die grüne Liste (CAN-sendefähige Knoten oder deren AUTOSAR-Äquivalente), blaue Liste (Messages oder AUTOSAR-PDUs), und weisse Liste (CAN-Signale oder deren ungefähre Äquivalente in AUTOSAR).
Alternativ kann die Anzeige auch als Baumstruktur (tree view) erfolgen. Das selektierte Signal (und evtl das gesamte Telegramm) wird in der Tabelle farblich markiert. Andere Signaldefinitionen aus demselben Telegramm werden mit einem hellblauen Rahmen markiert, andere Telegramme aus demselben Knoten mit einem hellgrünen Rahmen.

Sie können ein einzelnes Signal durch Klick in die entsprechende Zeile in der Tabelle oder in die Auswahlliste Signals of message anwählen.

Tip:: Wenn Hunderte von Signalen aus unterschiedlichen Knoten und Telegrammen in der Tabelle stehen, wählen Sie zuerst den Knoten, dann das Telegramm, und zuletzt das Signal. Dies geht viel schneller als durch hundert Definitionszeilen in der Tabelle zu scrollen !

Durch Doppelklick in die Tabelle (oder Rechtsklick, falls eine Zelle sich nicht im Editiermodus befindet) können Sie ein Popup-Menü öffnen welches Ihen alle Möglichkeiten des aktuell selektierten Knotens, Telegramms oder Signals zeigt.

Die Spalten in der Definitionstabelle sind:

VarName
Variablenname. Wird in einem anderen Kapitel erklärt.
Bus Nr
1 für das erste CAN -Interface, 2 für das zweite CAN-Interface (falls die Hardware zwei CAN-Schnittstellen bietet, z.B. "MKT-View")
NodeName, MsgName, SigName
Name eines Knotens, einer Message (=bestimmtes CAN-Telegramm), und eines Signals. Stammt aus CANdb-Datei.
Type
Datentyp. Bei Signalen die per CANdb-Datei beschrieben werden, gibt's hier nur "Signed" und "Unsigned" (ein gewaltiger Unterschied zu CANopen !)
Unit, Factor, Offset, Min Value, Max Value
Eigenschaften eines signals, stammen aus CANdb file. Einige dieser Eigenschaften werden später in Variablen übernommen.
Mapping
Wird später von der Firmware benötigt, um ein Signal aus einem CAN-Telegramm zu extrahieren. Der erste Parameter ist die Bitposition des niederwertigen Bits innerhalb des CAN-Telegramms; unabhängig davon ob INTEL oder MOTOROLA werden die Bits im "ersten" Byte des Telegramms immer von 7..0 numeriert (im Gegensatz zu einigen CANdb-Editor-Programmen, wo zu Ihrer Verwirrung eine völlig andere Zählweise verwendet wird).
Siehe auch: Hinweise zur Bit-Zählweise innerhalb eines Frames am Ende dieses Kapitels.
Attributes
Attribute werden im 'UPT' bislang nicht verwendet.
Message Definition
Wird später benötigt, um den CAN-Controller so zu programmieren damit er eine bestimmte MESSAGE (=CAN-Telegramm) empfangen kann. Der erste Teil der Definition ist der CAN identifier, der zweite Teil ein Flag ob 11- oder 29-bit identifier verwendet werden soll (standard oder extended frames)
Multiplexer (alias "Multiplexor" oder "Mode Signals" und "Mode-dependent signals")
Multiplexer werden gelegentlich verwendet, um mehr Signale mit nur einem CAN-Message-Identifier zu verteilen, als die Größe des CAN-Datenfeldes erlaubt.
Abhängig vom Wert des Multiplexers wird der Rest des CAN-Datenfeldes unterschiedlich decodiert. Da sich (im Gegensatz zur AUTOSAR-PDUs) der CAN-Signal-Multiplexer immer in derselben Message enthalten ist, mit der auch das gemultiplexte Signal transportiert wird, wird im Programmiertool (wie auch im CAN-Simulator) das folgende Format für den Multiplexer verwendet (ohne CAN-Message-ID):
Multiplex-Wert, Position des niederwertigen Bits im Datenfeld, Länge des Multiplexers in Bits, 'I'(ntel)/'M'(otorola)-Format .
Comment
Hier könnten ein paar Buchstaben aus dem 'comment'-Feld einer Signaldefinition angezeigt werden (Quelle: DBC-Datei).

Hinweis 1 :: Abgesehen von der Spalte VarName macht es keinen Sinn in dieser Tabelle irgend etwas zu editieren ! Verwenden Sie einen externen "CAN database editor" (z.B. von Vector oder Kvaser) um Signaldefinitionen in der *.dbc-Datei zu ändern, und importieren Sie die Definitionen erneut. Das Terminal-Programmiertool ist kein CANdb-Editor !
Hinweis 2:: In älteren Versionen des Programmiertools war es notwendig, vor dem Laden neuer CANdb-Dateien den alten Inhalt der Tabelle zu löschen. Nichtbeachten dieser Regel führte zu einem Chaos aus mehrfach definierten KNOTEN+MESSAGES+SIGNALEN, weil aus der CANdb-Datei geladene Signaldefinitionen grundsätzlich am Tabellenende angehängt wurden.
In den aktuelleren Versionen wird jede neu eingelesene Definition zunächst mit dem Tabelleninhalt verglichen. Falls die Definition eines Signals (inkl. KNOTEN- und MESSAGE-Namen) bereits existiert, erscheint ein Warnhinweis. Sie müssen dann entscheiden, ob die alte Signaldefinition überschrieben werden soll (wobei der eventuell vorhandene Variablenname erhalten bleibt) oder ob die aus der Datei gelesene Signaldefinition wie früher an die Tabelle angehängt werden soll. In letzterem Fall müssen Sie die doppelt vorhandenen Definitionen später selber entfernen.
Hinweis 3:: Eine 'Historie' der letzten 8 geladenen CAN-Datenbanken (*.dbc, *.arxml) wird als Teil der Terminal-Applikation abgespeichert. Dies bietet Ihnen eine Kontrollmöglichkeit, welche CAN-Dateien zum Erstellen eines Projektes verwendet wurden, und erleichtert das Neu-Laden von aktualisierten CANdb-Dateien, denn die CAN-Datenbank-Import-Historie enthält auch das Datum (timestamp) der geladenen Dateien.

Das Layout eines CAN-Telegramms kann auch in graphischer Form angezeigt werden. Dies hilft manchmal, um Missverständnisse mit der Bitzählung innerhalb eines CAN-Datenfeldes zu vermeiden (da manche CANdb-Editoren die Bits bei Signalen im Motorola-Format "rückwärts" zählen. Wir verwenden dagegen immer die gleiche Zählweise für Bits im CAN- oder LIN- Datenfeld, auch in der Script-Sprache).
Hier ein Beispiel für die graphische Anzeige eines CAN-Telegramms im Programmiertool (dazu den Button Grafik auf der Registerkarte CAN anklicken) :

Graphic display of a CAN message's signal layout
Grafische Anzeige einer CAN-Message (Layout).
Schraffierte Felder kennzeichnen den Multiplexer ("multiplexor") des momentan selektierten Signals.
Pfeile kennzeichnen Signale; sie zeigen vom LSB (Anfang) bis zum MSB (Pfeilspitze).
Details zum Anzeigefenster 'CAN Message Layout' folgen später.

Die Variablennamen werden im nächsten Schritt definiert, wenn Sie einige der importierten Signaldefinitionen für die Verwendung in Ihrer Anwendung auswählen.

Überprüfen und Auswählen von CAN-Signal-Definitionen

<< vorheriger Schritt nächster Schritt >>

Um Signale auf dem Display anzuzeigen (oder sie in anderer Form im Terminalprogramm zu nutzen), müssen Sie einen eindeutigen Variablennamen für jedes verwendete Signal bereitstellen.
Im Gegensatz zu einem CAN-Signal-Namen muss ein Variablenname immer mit einem Großbuchstaben beginnen, und ein Variablenname darf bei manchen Geräten maximal 8 Buchstaben umfassen (Ziffern an Position 2..8 sind zulässig) !

Im unten gezeigten Beispiel ist ein CAN-Signal (hier: "FourSines1" selektiert, und bereits mit einer Variablen verbunden (hier: mit dem gleichen Namen wie das Signal, da dessen Namen kurz genug ist).

Sie können den Variablennamen entweder in der entsprechenden Tabellenspalte eingeben, oder -durch Doppelklick in die Tabelle- einen Variablenamen automatisch aus dem Signalnamen erzeugen lassen. Das Programmiertool wird den Namen dabei ggf. abkürzen.

Durch Doppelklick in die Spalte VarName der Definitiontabelle öffnet sich ein Popup-Menü, mit dem Sie einen Variablennamen automatisch erzeugen oder entfernen lassen können. Alle Signale, bei denen "VarName" definiert ist, werden später in die Registerkarte "Variablen" übernommen (im nächsten Schritt).

Wählen Sie nur die CAN/CAN-FD-Signale aus, die sie wirklich zur Steuerung Ihres Terminalprogramms brauchen, denn die Anzahl von Anzeige-Variablen ist begrenzt. Dies hängt von der verwendeten Firmware ab, bei kleinen Systemen waren z.B. 40 nur Variablen definierbar, in "großen" Systemen mit mehr Speicher deutlich mehr. Sie können die tatsächlich mögliche Anzahl unter General Settings ablesen, allerdings nur nach einem erfolgreichen Programm-Up- oder Download aus einem 'echten' Terminal. (Die General Settings sind z.T. fest in der Firmware verankert, das Programmiertool hat davon per se "keine Ahnung" !).

Nachdem einige Signale wie oben beschrieben zur Kopplung mit Anzeige-Variablen ausgewählt sind, erscheint ein Statustext auf der Registerkarte "CANdb" wie folgt:

"5 signals in table, 4 will be used as variable"

Um diese Anzeige zu aktualisieren, klicken Sie auf "Check Table" oberhalb der Definitionstabelle.

Vorsicht :

Die CAN-Signal-Import-Funktion ist absolut kein Ersatz für einen CANdb-Editor, es findet keine Überprüfung der Tabelleneinträge statt. Sie können trotzdem einzelne Zellen in der Tabelle editieren, falls die Inhalte offensichtlich falsch sind (z.B. wenn ein CAN-Identifier geändert wurde, und Sie das CANdb-File nicht neu importieren wollen oder können).
Es gibt keine Möglichkeit, Änderungen in der Tabelle in ein CANdb-File zurückzuschreiben. Darum ist das Editieren der Tabelle (außer der Spalte VarName) auch reichlich sinnlos. Sie sollten lieber die Quelle (in diesem Fall das CANdb-File) editieren und die modifizierte Datei neu importieren.
Der Inhalt der Signal-Definitions-Tabelle wird mit im Terminalprogramm (*.cvt) abgespeichert. Dadurch steht Ihnen der Inhalt der Tabelle auch in der nächsten Sitzung wieder zur Verfügung, auch wenn Sie keinen Zugriff mehr auf die Quelle (die *.dbc-Datei) mehr haben.
Die in der *.cvt-Datei enthaltenen CAN-Signal-Definitionen können bei manchen Geräten auch zum Decodieren des CAN-Empfangs per 'Snooper' verwendet werden.

In der Baumansicht werden alle zum Empfang (aus Sicht des Anzeigegerätes) markierten Signale mit einem grünen Symbol markiert. Zu sendende Telegramme werden rot markiert (Details dazu in einem späteren Kapitel). Signale, die noch nicht mit einer Anzeige-Variablen verbunden wurden (und daher weder 'gesendet' noch 'empfangen' werden), sind in der Baumansicht wie im folgenden Beispiel grau markiert.

(Beispiel mit zum Senden und für den Empfang markierten Signalen;
Quelle: <Programmiertool>/programs/CdbSendT.cvt )

Nachdem Sie alle benötigten Signals für Ihre Anwendung ausgewählt (und geeignete Variablennamen bereitgestellt) haben, sind Sie bereit für den nächsten Schritt - nämlich einige CANdb-Signal-Definitionen in neue Anzeige-Variablen zu erzeugen.

Übertragen von CAN-Signal-Definitionen in Variablen-Definitionen

<< vorheriger Schritt nächster Schritt >>

Wenn mindestens ein Signal mit einer Variablen verbunden ist, wird der Transfer-Button auf der Registerkarte CANdb aktiviert:

Klicken Sie auf Ready, transfer to Variables wenn alle CAN-Signale die Sie in ihrer Applikation brauchen, durch Eintragen eines passenden Variablennamens selektiert sind.

Das Programmiertool wird dann auf die Registerkarte Variablen umschalten.

Alle Variablen, die mit einem CAN-Signal verbunden sind, erhalten hier (in der Variablendefinitionstabelle) die Kanalnumber "30" wie hier gezeigt:

Vergessen Sie die Spaltenüberschrift "PDO/SDO-Definition" wenn eine Variable mit einem CAN-Signal verbunden ist ! In diesem Fall enthält diese Spalte einen Teil der CAN-Signal-Definition, mit BUS-Nummer, CAN-ID, Position des niederwertigen bits innerhalb des CAN-Telegramms, die Anzahl von Datenbits des Signals, und ein Flag ob das Signal im "Intel"- oder "Motorola"-Format vorliegt. Versuchen Sie nicht, hier die Definitionen zu ändern, es ist zwecklos ! Verwenden Sie einen CANdb Editor um die "Quelle", nämlich die CANdb-Datei (*.dbc) zu editieren, und importieren Sie die Signaldefinitionen erneut !

Weitere Informationen über die Registerkarte Variablen finden Sie im Handbuch des Programmiertools (nicht CANdb-spezifisch). Die Eigenschaften (properties) Min Value und Max Value werden mit den entsprechenden Werten aus der Signaldefinition (CANdb) vorbesetzt, Sie können diese Eigenschaften allerdings ändern wenn dies unbedingt nötig ist.

Normalerweise wählt das Programmiertool den am besten geeigneten Datentyp für die Variable automatisch. Stört dieser Automatismus, kann dies -wie hier beschrieben- geändert werden.

Unglücklicherweise wird im CANdb-File kein default-Wert für ein Signal definiert, darum ist es an dieser Stelle unmöglich einen Default-Wert anzugeben der auf dem Display angezeigt (oder editiert) wird solange kein gültiger Wert vom CAN-Bus empfangen wurde.

Weil das Anzeigeterminal ausschließlich ein Empfänger aber kein Sender sein soll(*), kann es keine Sendung eines neuen Wertes anfordern (ganz im Gegensatz zu CANopen, wo entsprechende Protokolle definiert sind).

Spezialität für "aperiodisch" (oder "selten") übertragene Signale

Ein Problem kann bei aperiodisch gesendeten Signalen//Messages auftauchen. Falls ein Signal auf der aktuellen Anzeigeseite nicht verwendet wird, wird es möglicherweise vom CAN-Controller nicht empfangen (abhängig von der Anzahl verwendeter CAN-Messages, s.U.). Wenn Sie dann zu einer Anzeigeseite umschalten, auf der das Signal angezeigt wird, könnte der Wert des Signals noch nicht verfügbar sein (weil das Signal noch nicht empfangen wurde).
Sollte dies ein Problem darstellen, setzen Sie die "Update Time" (bzw hier "Transmission Cycle") der Variablen auf "APERIODISCH" (aperiodic). Das Terminal wird dann versuchen, die Message (in der das Signal enthalten ist) immer zu empfangen, egal ob die Variable (die mit dem Signal verknüpft ist) momentan gebraucht wird oder nicht. Siehe auch: Strategie zur Belegung von CAN-Message-Objekten im Anhang dieses Dokuments.

(*) Ursprünglich lautete eine Forderung für das Anzeigeterminal: "Es (das Terminal) darf nur empfangen aber nix senden"... dann "Es soll nur empfangen"... irgendwann "es könnte eventuell auch senden" ... mittlerweile "es muß aber auch senden können" ... demnächst gibt es eine Hardware-Variante die (hardwarebedingt) gar nicht senden kann, nicht mal CAN-acknowledge .... !!

Entwickeln und Testen der Anzeigeseiten des Terminalprogramms

<< vorheriger Schritt

Nachdem alle Variablen definiert sind (mit oder ohne Netzwerk-Verbindung), können Sie im Terminal-Programm (wie im Handbuch beschrieben) verwendet werden.

Im einfachsten Fall wird der Inhalt einer Variablen numerisch auf dem Display angezeigt. Zu diesem Zweck legen Sie eine neue Anzeigeseite an, fügen ein paar Anzeigezeilen an, und wählen die anzuzeigenden Variablen aus (für jede Zeile, in der ein numerischer Wert anzeigt werden soll. Verwenden sie den Stern ( asterisk, '*') als Platzhalter für die Ziffern, da Minuszeichen (-) als Platzhalter für das Vorzeichen und den Punkt (.) als Dezimalpunkt wie im folgenden Beispiel:

Die anzuzeigende Variable kann aus einer Liste auf dem Property-Panel "display line properties" ausgewählt werden. Siehe Beschreibung der Anzeige-Definitions-Tabelle im universellen Handbuch des Terminal-Programmiertools.

Zu Testzwecken kann der Inhalt einer Variablen auch im Watch-Fenster des Programmiertools angezeigt werden. Falls Sie über ein geeignetes CAN-Interface (und den passenden Treiber) verfügen, können Sie sogar die Funktion der Variablen mit "echten" Meßdaten vom CAN-Bus überprüfen.

Das Erscheinungsbild einer fertig programmierten Anzeigeseite kann im Fenster des LCD-Simulators getestet werden, dort können einige Anzeigeelemente (normale Displayzeilen) per Maus noch verschoben werden:

Spezialitäten wie Icons, Menus, Ereignis-Verarbeitung, werden hier (im CANdb-spezifischen Teil des Hilfesystems) nicht erklärt.
Weitere Infos zum Anlegen, Testen und Modifizieren eines Programms finden Sie im allgemeinen (d.h. nicht CANdb-spezifischen) Handbuch des Terminal - Programmiertools.

Der nächste Schritt wäre das Übertragen (z.B. Hochladen) der Applikation in ein 'echtes' Anzeige- oder Bediengerät.

Optionen und Konfigurationsmöglichkeiten

Im vorhergehenden Kapitel wurde der prinzipielle Ablauf für die Erstellung einer neuen Applikation mit Import der CAN-Definitionen aus *.DBC-Dateien beschrieben (oder vergleichbaren Datenbanken).
Dieses Kapitel beschreibt weitere Optionen bezüglich CAN-Datenbanken, die z.B. beim 'Aktualisieren' oder Anpassen einer bereits existierenden Applikation für ein anderes Fahrzeug (mit 'neuen' DBC-Dateien) helfen.

Dialog zum Ersetzen von Variablen / Signalen auf einer Anzeigeseite

Wenn Sie auf einer schon existierenden (oder recycelten) Anzeigeseite die dort angezeigten Variablen durch neue Variablen / CAN-Signale ersetzen wollen, verwenden Sie den in einem anderen Dokument beschriebenen Dialog mit dem Titel

"VARIABLEN oder SIGNALE für Seite XYZ ersetzen"

CAN-Datenbank-Import-Historie für das 'Neu-Laden' von Dateien

Die CANdb-Datei-Import-Historie ist eine Liste, in der die letzten 8 geladenen CAN-Dateien (*.dbc, geplant: auch *.arxml) gespeichert werden. Bei einer neu erstellten Terminal-Applikation ist diese Liste leer. Der Inhalt der Historie kann duch Anklicken des Buttons History auf der CAN-DB-Import-Seite angezeigt werden.

Eine CAN-Datenbank-Import-Historie könnte z.B. wie folgt aussehen:

(screenshot CANdb file history)

Sie können einen Eintrag in dieser Liste (per Maus) selektieren und dann "Ok" anklicken. Dann erscheint eine Dateiauswahlbox, in der die "alte" Datei bereits voreingestellt ist. Dies erleichtert das Neu-Laden von Signaldefinitionen aus aktualisierten CAN-Dateien.

Hinweise

Das "Neu-Laden" von in der Liste gepeicherten Dateien funktioniert nur, wenn die alte Pfadangabe noch gültig ist !
Der neueste Eintrag steht immer am Anfang der Liste. Die ältesten Einträge stehen unten. Beim Laden der 9. Datei verschwindet der älteste Listeneintrag.
Die Liste ist nicht nach dem Datei-Datum ("DOS-Datei-Datum") sortiert, sondern nach dem Datum des Ladens.
CAN-Bus-Nummer '255' dient als Dummy für Datenbanken, die mit der Option "All/Any" (d.h. von allen Bussen 'parallel' empfangen bzw. auf allen Bussen gleichzeitig Senden) importiert wurden.
Um mehr von den Dateipfaden zu sehen, vergrößern Sie das Historien-Fenster.
Die komplette Datenbank-Import-Historie kann per Popup-Menü (Button mit der Aufschrift 'Menü' auf der Registerkarte 'CANdb') gelöscht werden. Selbstverständlich werden dadurch nicht die Datenbanken selbst, sondern nur der Verlauf des Imports von *.dbc- bzw. *.arxml-Dateien in die momentan geladene Applikation gelöscht.
Siehe auch: Neu-Laden von CAN-Datenbanken ohne Trennung von Signalen und Variablen

Optionen für den Import von CANdb-Dateien / Überschreiben bereits importierter Daten

Für einen bestimmten Einsatzzweck war es nötig, die NODE- und MESSAGE-Namen beim Vergleich alter/neuer Signaldefinitionen zu ignorieren. Normalerweise wird ein Eintrag in der Signaltabelle nur überschrieben, wenn sowohl NODE+MESSAGE+SIGNAL-Name bei neuer und alter Definition übereinstimmen. Klicken Sie auf die Schaltfläche Menü, und wählen Sie den Eintrag Optionen für CANdb-Datei-Import um dies ggf. zu ändern.

(screenshot CANdb import options)

Verfügbare Optionen für den Import von CANdb-Dateien:

Ignore NODE NAME: Wenn diese Option aktiv ist, ignoriert das Programmiertool den NODE-NAMEN eines Signals wenn es entscheiden muss ob ein alter Eintrag überschrieben werden soll, oder ob die aus der CANdb-Datei gelesene Signaldefinition an die Tabelle angehängt werden soll.
(Unabhängig davon wird der NODE-NAME aus der Datei immer übernommen; das "Ignorieren" bezieht sich nur auf den Vergleich).
Ignore MESSAGE NAME: ähnlich wie Ignore NODE NAME, hier allerdings für den MESSAGE-NAMEN eines Signals.

Hinweis: Normalerweise sind diese Optionen beide passiv ("aus"). Sie sollten nur aktiviert werden, wenn sichergestellt ist das allein die Signalnamen bereits eindeutig sind (und nicht erst in der Kombination mit dem Node- und Message-Namen) !

Siehe auch: Einlesen von CAN-Datenbanken

Neu-Laden von CAN-Datenbanken ohne Trennung von Signalen und Variablen

Wie bereits in Kapitel 2 erwähnt wurde, können CAN-Datenbänke auch erneut geladen werden (d.h. "erneuert" aus der Quelle, um Änderungen in der Datenbank auch in die Display-Applikation zu übernehmen), ohne dabei die Verbindung zwischen CAN-Signalen (die ursprünglich in einer alten Datenbank definiert waren) und Anzeige-Variablen zu trennen.
Zu dem Zweck wird die neuere Datenbank einfach über die alten, bereits importierten Daten 'überladen'. Dabei keinesfalls vorher die Funktion 'die gesamte Tabelle löschen' aufrufen (im Menü auf Registerkarte 'CANdb'), denn dies würde die Information, welcher CAN-Knoten/CAN-Message/CAN-Signal mit welcher Anzeigevariablen verbunden ist, löschen. Sie müssten alle Zuordnungen mühsam einzeln wiederherstellen.
Beim 'Überladen' sucht das Programmiertool nach übereinstimmenden Knoten-, Message-, und Signalnamen zwischen alten und neuen CAN-Definitionen. Bei Übereinstimmung wird die neue Signaldefinition an der Stelle in der Tabelle auf Registerkarte 'CANdb' abgelegt, an der vorher die 'alte' Definition stand (inkl. Knoten-, Message- und Signalnamen). Lediglich der Eintrag in der Spalte 'VarName' (=Name der dem CAN-Signal zugeordneten Display-Variablen) bleibt erhalten.
Beim ersten in der Tabelle bereits vorhandenen Signalnamen meldet sich das Programmiertool mit der folgenden Meldung:

Beantworten Sie diese Frage mit 'Ja' / 'Yes' um alte (bereits existierende) Signal-Definitionen mit dem gleichen Namen zu ersetzen, und nur neue (bis dato unbekannte Signale) am Ende der Tabelle anzuhängen ('append').

Nach dem 'Erneuern' (Neu-Laden) der letzten Datenbank klicken Sie wie bereits in Kapitel 2 beschrieben auf den nun blinkenden Button 'Fertig, in Variablen umsetzen', um die Änderungen auf der Registerkarte 'CANdb' (importierte CAN-Datenbanken) auf die Registerkarte 'Variablen' (und damit in die Applikation) zu übernehmen.

Da in diesem Fall alle Display-Variablen-Namen erhalten bleiben, sind keine Änderungen auf den Anzeigeseiten nötig (mit einer Ausnahme: Werden in der neuen CAN-Datenbank neue Signalnamen verwendet, müssen Sie die entsprechenden Signale selbst, d.h. manuell, erneut mit den entsprechenden Display-Variablen verbinden).

Farbig markierte Zellen in der Tabelle nach dem Neu-Laden von CAN-Datenbanken

Das Programmiertool unterstützt Sie seit 01/2021 beim 'Neu-Laden' bzw Aktualisieren der CAN-Datenbank mit den im Folgenden spezifizierten farbigen Markierungen in der Definitionstabelle.
Alle Zeilen in der 'CANdb'-Tabelle, die beim Neu-Laden der CAN-Datenbank erfolgreich aktualisiert (aber nicht neu angelegt) wurden, werden mit einem grünen Hintergrund markiert. Bei diesen Einträgen bleiben eventuell schon vorhandene Variablennamen wie im unten gezeigten Screenshot erhalten.
Neue Einträge aus der importierten Datei, die am Ende der Tabelle angehängt wurden (ohne existierende Einträge zu überschreiben) erhalten einen gelben Hintergrund.

Farbig markierte Zellen in der Tabelle unter 'CANdb' nach Datenbank-Import

Bei gelb markierten Einträgen können logischerweise noch keine Variablennamen für die Verknüpfung mit den neuen CAN-Signalen vorhanden sein. Sind die neuen Signale für Ihre Applikation von Interesse, kann wie in Kapitel 1 beschrieben ein neuer Variablenname erzeugt werden (Rechts-Klick in Spalte 'VarName'). Dank der gelben Markierung können alle neuen Einträge beim 'Überfliegen' am Ende der Tabelle schnell gefunden werden.

Hinweis:: Ähnliche Farben für die Markierung von aktualisierten und neu angehänten Tabellenzeilen werden auch in der Tabelle mit den Definitionen aller Display-Variablen, z.B. nachdem die wie oben beschrieben importierten CAN-Datenbanken in Variablen umgesetzt wurden.

Popup-Menü zum Importieren von Datenbanken für weitere / alle CAN-Busse

Über den Button 'Lade andere...' auf der Registerkarte 'CANdb' (CAN-Datenbanken) kann das unten gezeigte Popup-Menü geöffnet werden, um Datenbanken für weitere oder alle (beliebige Busse) zu importieren. Die letztgenannte Option ist allerdings 'mit Vorsicht' zu geniessen, denn das Senden eines aus einer Datenbank importierten CAN-Message-Identifiers auf allen CAN-Schnittstellen des Gerätes könnte schnell zu unbeabsichtigt hoher Buslast oder sogar zu Identifier-Kollisionen führen.

→

Die im Juli 2021 implementierte Funktion 'Datenbank für ALLE CAN-Busse laden' hat folgende Besonderheit:

CAN-Messages und die darin enthaltenen Signale werden nicht 'fest' einem bestimmtes Netzwerk (CAN-Interface) zugeordnet.
Alle per Interface "CAN1", "CAN2", "CAN3" oder "CAN4" empfangenen Message-Identifier werden mit den für "alle" Busse importierten Definitionen verglichen (in der Tabelle erkennbar an Bus = "Any/All"). Die Bus-Nummer spielt für den Empfang keine Rolle.
Im englischen Dummy-Namen bezieht sich "Any" auf den Empfang: Receive from *any* bus.
Die aus der "für ALLE CAN-Busse" importierten, zu sendenden Messages werden (sofern die entsprechenden Interfaces sendebereit sind) sowohl auf dem Interface "CAN1", als auch(!) auf "CAN2", "CAN3" und "CAN4" gesendet.
Im englischen Dummy-Namen bezieht sich "All" auf das Senden: Transmit on *all* buses.
Bei der internen Speicherung der CVT-Datei wird "Any/All" als Bus-Nummer 255 (dezimal) codiert.

Popup-Menü mit weiteren Operationen für CAN-Datenbanken

Der 'Menü'-Button auf der Registerkarte 'CANdb' öffnet ein weiteres Popup-Menü mit den folgenden Einträgen:

Optionen für das Umsetzen von CAN-Signalen in Anzeige-Variablen

In alten Programmversionen wurden CAN-Signale grundsätzlich in Variablen mit dem Datentyp "floating point" umgesetzt.

In bestimmten Fällen (z.B. wenn ein 32-Bit-Wert binär angezeigt werden soll) ist es allerdings besser, das Programmiertool automatisch dem am besten geeigneten Datentyp umzusetzen, der auch vom Interpreter unterstützt wird.

Das Programmiertool geht beim Umsetzen von CAN-Signalen in Variablen folgendermaßen vor:

Wird ein Wert auf dem CAN-Bus als Fliesskommazahl übertragen, erhält die Variable auf jeden Fall den Typ "Floating Point"
Wird ein Wert auf dem CAN-Bus als Integerzahl übertragen, und ist der Skalierungsfaktor oder Skalierungsoffset des Signals ein Dezimalbruch (d.h. eine Zahl mit Nachkommaanteil), erhält die Variable ebenfalls den Typ "Floating Point"
Wird ein Wert auf dem CAN-Bus als Integerzahl übertragen, und sind sowohl Skalierungsfaktor als auch Skalierungsoffset des Signals ebenfalls Integerzahlen (d.h. ganze Zahlen), erhält die Variable ebenfalls den Typ "Integer" (signed oder unsigned, s.U.)
Wird ein Wert auf dem CAN-Bus als UNSIGNED Integer übertragen, und sind sowohl Skalierungsfaktor als auch Skalierungsoffset des Signals positive Integerzahlen, erhält die Variable ebenfalls den Datentyp "UNSIGNED Integer"

Falls dieser Automatismus zu Problemen führt, kann auf der Registerkarte "CANdb" folgendes eingestellt werden:

Button Menü anklicken, den Eintrag Optionen zum Konvertieren von CAN-Signalen in Variablen anwählen,
und in der Auswahlliste die Option Variablen-Typ automatisch ermitteln ausschalten. Im Normalfall sollte diese Option allerdings verwendet werden, um unnötige Fließkomma-Operationen zu vermeiden.

Hinweis:

Bei Fließkommazahlen werden führende Nullen in der Anzeige unterdrückt, und der Dezimalpunkt automatisch gesetzt. Ein Wert von 255.0 wird in der Anzeige daher niemals als "2.55" erscheinen, auch wenn im Format-String nur eine Ziffer vor dem Dezimalpunkt, und zwei Ziffern nach dem Dezimalpunkt definiert sind. Bei Integerzahlen werden führende Nullen i.A. nicht unterdrückt, und der Dezimalpunkt ohne Umrechnung des Zahlenwertes "irgendwo" eingefügt. Ein Wert von 255 kann in der Anzeige daher als "2.55" erscheinen. Dies ist kein Fehler sondern Absicht, da ältere Geräte (mit 8-Bit-CPU) keine Fliesskommazahlen unterstützten, und die neueren Geräte (mit 32-Bit-CPU) zu den älteren Geräten funktionskompatibel sein sollten.

Empfangsüberwachung (Signal Timeout Monitor)

In den (alten) CANdb-Datenbanken (*.dbc) wurde leider kein Sendezyklus von Signalen und Messages angegeben, darum gibt es keine einfache Methode zum Erkennen eines Verbindungsausfalls zwischen Sender und Empfänger (hier: Terminal). Die Firmware verfügt aber über eine einfache Timeout-Überwachungsfunktion für CAN-Signale, die sie möglicherweise verwenden können. Die genaue Funktion wird weiter unten beschrieben.

Wenn alle Signale periodisch übertragen werden, können Sie eine globale Überwachungszeit mit der folgenden Funktion einstellen (und damit die Überwachung aktivieren):

Syntax im Display-Interpreter:: @signals.timeout=<Intervall in 0.1 Sekunden>
@signals.timeout=0
@sigs.tmo=0 (das Gleiche, abgekürzt)
Syntax in der Script-Sprache:: CAN.rx_timeout := <Intervall in Millisekunden>

Mit <intervall> größer Null wird die Überwachung aktiviert. Dies bedeutet, wenn ein Signal nicht innerhalb dieser Zeit empfangen wurde, wird es automatisch ungültig (was dem Urzustand nach dem Einschalten entspricht). Die Intervallzeit wird als Vielfaches von 0.1 Sekunde angegeben, daher bedeutet @signals.timeout=5 dass jedes Signal mindestens alle 500 Millisekunden übertragen werden muss.

Mit <interval> = 0 (Null) wird die Überwachung deaktiviert. Dies bedeutet: Variablen die mit Signalen verbunden sind bleiben "ewig" gültig (sobald das Signal einmal empfangen wurde).

Funktion des Signal-Timeout-Monitors

Beim Empfang einer CAN-Message wird ein interner Timer mit dem Wert aus signals.timeout geladen. Jede Variable (~ jedes empfangene Signal) hat einen eigenen Timer ! Beim Empfang werden darüberhinaus alle Variablen, die mit der Message verbunden sind, auf gültig gesetzt.
Alle 100 Millisekunden wird die komplette Variablentabelle durchsucht. Wenn der Überwachungstimer einer Variablen (die mit einem CAN-Signal verbunden ist) nicht Null ist, wird er dekrementiert. Wenn der dekrementierte Timer abläuft (d.h. negativ wird), wird die entsprechende Variable (~Signal) ungültig gesetzt.
Auf dem Display werden alle gültigen, numerisch angezeigten Variablen normal angezeigt (z.B. "Temp = 123.45"), alle ungültigen Variablen werden mit Platzhaltern für die Ziffern angezeigt (z.B. "Temp = ****.**").

Hinweise

Das Abschalten der Empfangsüberwachung (@signals.timeout=0) führt nicht (sofort) dazu, dass alle Variablen wieder "gültig" werden ! Erst bei erfolgreichem Empfang wird die Variable wieder gültig.
Das Einschalten der Empfangsüberwachung (z.B. @signals.timeout=5) kann dazu führen, daß viele Signale gleichzeitig ungültig werden. Sie sollten dieses Kommando nur an einer Stelle in Ihrem Programm einsetzen, vorzugsweise im "page enter"-Event der Start-Seite (page 0). Dann wird die Empfangsüberwachung genau einmal (beim Einschalten) aktiviert.
Für spezielle Anwendungen müssen Sie möglicherweise beim Ausfall eines "wichtigen" Signals auf eine bestimmte Anzeigeseite umschalten. Dazu können Sie per Interpreter das "valid"-Flag einer Variablen als Anhang ".va" nach dem Variablennamen auslesen, z.B. "Temp.va". Nutzen Sie dies vorzugsweise in einer globalen Event-Definition, damit die Abfrage unabhängig von der aktuellen Anzeigeseite funktioniert.

Zurück zur Übersicht

Spezielle Interpreter-Funktionen für Variablen, die mit CAN-Signalen gekoppelt sind

Nur verfügbar in Geräten mit ARM-CPU (MKT-View II, III, IV, ..) !

Bei den oben genannten Geräten ist es möglich, die Definition von Variablen (zumindest teilweise) zur Laufzeit zu verändern. Dazu dienen die in einem anderen Dokument aufgelisteten Komponenten einer Variablen. Die im Folgenden aufgezählten Komponenten beziehen sich speziell auf Variablen, die mit CAN-Signalen verknüpft sind:

<VariableName>.ci : Liest oder ändert den CAN-Identifier des Signals, mit dem die Variable <VariableName> verbunden ist.
Beispiel: Eine Variable namens "FourSines1" sei mit einem CAN-Signal verbunden. Dann liefert der numerische Ausdruck
FourSines1.ci
den CAN-Identifier der Message, in der dieses Signal enthalten ist (inklusive des 11/29-bit-ID-flag in Bit 29, und der CAN-Bus-Nummer in Bits 30 bis 31).
Das Interpreterkommando (hier: Zuweisung)
@FourSines1.ci = 0x123
würde den CAN-Identifier auf 0x123 setzen (mit 11-bit CAN-ID, weil in diesem Beispiel Bit 29 nicht gesetzt ist; und für den ersten CAN-Bus weil weder Bit 30 noch Bit 31 im zugewiesenen Wert gesetzt sind).
Hinweis: Das obige Beispiel stammt aus der Demo-Applikation "MV2_DEMO.CVT", Seite "Standard Signal Test". Diese Datei ist im Installationsarchiv im Unterverzeichnis programs/MKTview2 enthalten. Bitte beachten Sie, daß das ändern des CAN-Identifiers einer Variablen eine Umprogrammierung des CAN-Controllers zur Folge haben könnte, wodurch die Funktion des CAN-Loggers vorübergehend gestört werden kann (einige empfangene Telegramme können verloren gehen).
<VariableName>.fb : first bit (des Signals innerhalb des Datenfeldes eines CAN-Telegramms)
<VariableName>.nb : number of bits (des Signals als Rohwert im CAN-Telegramm)
<VariableName>.bo : byte order. 0 = Intel, 1=Motorola
<VariableName>.st : raw signal type. 0 = Unsigned integer, 1 = Signed integer, 2 = IEEE single precision floating point.
<VariableName>.sf : scaling factor
<VariableName>.so : scaling offset . Dient (zusammen mit .sf) zur Umrechnung vom "Rohwert" in die physikalische Größe.

Seit Oktober 2012 sind die oben aufgeführten Komponenten auch in der Script-Sprache nutzbar.

Zurück zur Übersicht

Signalwert/Text-Tabellen

Manche in CAN-Datenbanken definierte Signale können statt als Dezimalzahl auch in Form von benutzerdefinierten Texte zur Anzeige gebracht werden.

Einige Datenbanke (*.dbc-Dateien) enthalten dazu Wertepaare wie im folgenden Beispiel. Diese Wertepaare können vom Programmiertool importiert werden, und werden dann zusammen mit anderen Parametern in die Definition von 'Display-Variablen' übernommen.
Beispiel: Ein Signal vom Getriebe könnte den momentan eingelegten Gang anzeigen, wobei auf dem Display statt der dezimalen Werte entsprechende Texte angezeigt werden sollen:

255=SNA,0=P,1=N,2=R,3=D1,4=D2,5=D3,6=D4,7=D5,8=D6

Jedes Wertepaar repräsentiert einen bestimmten Signalwert, z.B. "P" für die Parkposition, "N" für "Leerlauf", "R" für "Rückwärtsgang", und so weiter. "SNA" ('Signal Not Available') wird gerne verwendet, wenn vom Sensor zwar Daten kommen, der Sensor selbst aber erkannt hat, dass der Wert ungültig ist, z.B. bei Drahtbruch. Für diesen besonderen Wert wird oft der maximal mögliche CAN-Rohwert verwendet (mit "allen Bits gesetzt", z.B. 255 bei einem 8-Bit-Signal ohne Vorzeichen).

Hinweis: Die numerischen Werte in der Tabelle sind offenbar immer die 'CAN-Rohwerte' - nicht die für die Anzeige skalierten physikalischen Werte.

Beim Empfang von CAN-Signalen, für deren Anzeige wie hier beschrieben die importierte Wertetabelle verwendet werden soll, erfolgt die 'Decodierung' wie folgt) :

Extraktion des "rohen" CAN-Signalwertes aus der empfangenen CAN-Message
Testen, ob für diese Signal (bzw. "Display-Variable") eine Wertetabelle importiert wurde
Wenn ja, den "rohen" CAN-Signalwert in der Tabelle suchen
Wurde ein passender Eintrag gefunden, den TEXT aus der Tabelle anzeigen.
Andernfalls fortfahren wie ohne Wertetabelle:
Konvertieren des Rohwertes (i.A. Integer) in den physikalischen Wert für die Anzeige (z.B. Skalierung mit Offset und Faktor)
Anzeige des physikalischen Wertes in numerischer Form (wenn kein passender Text für den ROHWERT gefunden wurde).

Hinweis: Die Gesamtlänge einer Wertetabelle darf i.A. 127 Zeichen (pro Variable) nicht überschreiten. Wertetabellen stehen nur bei Geräten mit 32-Bit-CPU zur Verfügung, z.B. MKT-View III / IV / V .
In der "CANopen"-Variante des Programmiertools und der Geräte-Firmware werden keine Wertetabellen unterstützt.

Für spezielle Anwendungen kann das Script auf die gesamte Wertetabelle zugreifen (display.GetVarDefinition(<Variablenname>).ValueTable).

Details zum Anzeigefenster 'CAN Message Layout'

Die bereits im Kapitel Import von Signaldefinitionen aus einer DBC-Datei gezeigte Funktion zum Anzeigen des 'CAN-Message-Layouts' (mit allen darin enthaltenen Signalen) wird in diesem Kapitel genauer erläutert. Sie eignet sich (seit 2020) nicht nur für CAN, sondern auch für CAN FD, mit bis zu 64 Datenbytes pro Message ("frame").

In der links gezeigten Grafik wird ein Teil des Datenfelds aus einem CAN FD - Rahmen mit insgesamt 20 Signalen mit je 16 Bit dargestellt (wie üblich, zum Vergrößern in die Grafik klicken). Im Gegensatz zu 'classic CAN' (mit maximal 8 Byte im Datenfeld) reicht selbst beim hier durch den Bediener vergrößerten Fenster der Platz nicht aus, um alle in der Message enthaltenen Signale gleichzeitig darzustellen.
Das Programmiertool aktiviert daher automatisch einen vertikalen Scrollbalken, mit dem der byte offset inkrementiert bzw dekrementiert werden kann (Beschriftung am linken Rand der Grafik).
Die Tabellen-Kopfzeile und die Legende am unteren Rand der Grafik werden natürlich nicht mitgescrollt.

Per Mausklick in die Tabelle unter 'Message Layout' kann das momentan selektierte Signal umgeschaltet werden. Das Programmiertool schaltet dabei nicht nur die Selektion im grafischen 'Message Layout'-Fenster, sondern auch die entsprechende Zeile in der Definitionstabelle 'CAN' um.
Ist das angeklickte Bit von mehreren ("gemultiplexten") Signalen belegt, kann durch mehrfaches Klicken auf dasselbe Bit der Reihe nach zu allen Signalen umgeschaltet werden.

Tipp:: Das mehrfache Anklicken eines Bits, um der Reihe nach alle damit "transportierten" CAN-Signale anzuzeigen, funktionert auch mit der CAN-Message-Layout-Anzeige im CAN-Simulator des Programmiertools.

Das momentan selektierte Signal wird in der Grafik (Tabelle) durch einen etwas dicker ausgezeichneten Pfeil markiert. Der Pfeil beginnt jeweils beim niederwertigen Bit des Signals, und endet an der Pfeilspitze mit dem höchstwertigen Bit des Signals.

Eine ähnliche Darstellung finden Sie u.A. auch beim frei verfügbaren CAN- Datenbank-Editor von Kvaser.

Vergrößerte Darstellung des momentan selektierten Signals
in der CAN / CAN FD Message Layout Anzeige,
mit Signalnamen in der Legende (unten).

Für die Numerierung von Bits innerhalb des Datenfeldes wird kompromisslos das auch in der Script-Sprache verwendete Prinzip verwendet, unabhängig davon, ob im Datenfeld Signale im "Motorola-Format" vorhanden sind oder nicht. Die Bitzählung beginnt bei Null, nicht Eins. Das oben gezeigte 16-Bit-Signal 'TwentySines20' mit Datenbits 304 bis 319(!) belegt daher die letzten 2 Bytes eines hypothetischen 40-Byte-Rahmens.

Senden von CAN-Telegrammen (mit per Datenbank definierten Signalen)

Bestimmte Terminals können (nach entsprechender Freischaltung durch den Hersteller) auch CAN-Signale senden.

Diese potentiell gefährliche Funktion ist nur in Geräten mit 32-Bit-CPU implementiert (d.h. nicht für MKT-View "Plus"). Per Default kann das programmierbare Terminal aus seiner Sicht CAN-Telegramme nur empfangen, aber nicht senden. Neben der hier beschriebenen Funktion ("Senden von CAN-Telegrammen mit automatischer Zusammenstellung des Inhalts per Datenbank") haben Sie noch die Möglichkeit, CAN-Frames per Display-Interpreter ("ctx") oder per Script-Sprache ("can_transmit") inklusive Message-Identifier, Länge, und bis zu 8 Datenbytes selbst zusammenzustellen und zu senden.

Hinweise:

Das Senden von CAN-"Signalen" ist ein freizuschaltendes Feature
- bitte nehmen Sie Kontakt mit dem Hersteller auf,
wenn die Funktion noch nicht freigeschaltet ist und Sie diese benötigen !
(den Preis für eine Freischaltung erfragen Sie bitte bei MKT Systemtechnik ).
Wird beim Einschalten des Gerätes, oder beim Aufruf des System-Menüs "CdbTX=NO" angezeigt,
dann kann das Senden von "CANdb"-Signalen nicht funktionieren !
Ferner muss das Flag 'signals.tx_exable' bzw. (im Script) CAN.tx_enable durch die Applikation gesetzt werden,
um das Senden von CAN-Signalen zu starten.
Wenn das Flag signals.tx_enable nicht gesetzt wurde (z.B. bei der Initialisierung auf "Seite Null",
dann wird das Senden von "CANdb"-Signalen ebenfalls nicht funktionieren !
Sollte dem CAN-Controller das Senden jeglicher Telegramme per System-Setup untersagt sein (d.h. "passiver CAN-Empfänger"),
dann darf auch das Senden von "CANdb"-Signalen nicht funktionieren !
Ist der CAN-Controller im Terminal nicht passend konfiguriert (z.B. Baudrate, Sample Point, falscher Abschlusswiderstand, etc),
dann kann auch das Senden von "CANdb"-Signalen nicht funktionieren !
Das Senden von "CANdb"-Signalen hat nichts mit dem Interpreterkommando ctx (CAN transmit) zu tun,
welche schon in den ältesten Geräten zur Anzeige von CAN("CANdb")-Signalen existierte.. anno 2002.
Lesen Sie bitte auch den Rest dieses Kapitels. Sollten Ihnen die fünf Minuten zum Lesen dieses Kapitels fehlen,
werden Sie später ohnehin Probleme haben - und Sie sollten gar nicht erst versuchen, CAN-Signale zu senden.

Warnung:

Sie sollten sehr gut mit 'Ihrem' CAN-Netzwerk vertraut sein, und sich genau über die möglichen Folgen des Sendens von CAN-Telegrammen bewusst sein, bevor Sie die hier beschriebenen Funktionen einsetzen ! Grund: Der Einsatz dieser Funktionen könnte katastrophale Folgen, schwere Unfälle, Personenschäden, Materialschäden, etc zu Folge haben ! (Denken Sie daran, was passieren könnte, wenn Ihre Applikation "aus Versehen" einen Befehl zum Zünden des Airbags bei 200 km/h senden würde, oder, wenn Sie aus Versehen den gleichen CAN-Identifier verwenden, der bereits von einem anderen [Ihnen bis dato unbekannten] Steuergerät gesendet wird... denn allein diese 'ID-Kollision' kann bereits zum 'Aussteigen' des CAN-Busses führen).

Sie wurden gewarnt ! Das gesamte Risiko des Einsatzes liegt bei Ihnen !

Die einfachste Möglichkeit, um dem Terminal (bzw. dem Programmiertool) mitzuteilen, welche in der CAN-Datenbasis definierten Telegramme gesendet werden sollen, ist folgende:

: Vor dem Import der CAN-Datenbasis, den Knotennamen des Terminals entsprechend einzustellen (unter der Voraussetzung, daß für alle Knoten/Steuergeräte entsprechende 'sprechende' Namen verwendet wurden, was leider nicht immer der Fall ist).

Klicken Sie dazu auf der Registerkarte 'CANdb-Daten' auf den Button 'Menü', wählen unter 'Optionen für CANdb-Dateiimport' den Eintrag 'Knotenname für ZU SENDENDE CAN-Telegramme', und importieren anschliessend wie bekannt die CANdb-Dateien (*.dbc). Bei übereinstimmenden Knotennamen werden die entsprechenden CAN-Telegramme (messages) und -Signale beim Import dann bereits zum 'SENDEN' (aus Sicht des Terminals) markiert, und später (bei der Umwandlung der markierten Signale in Variablen) mit dem Attribut 'TX' (d.h. Transmit, Senden) versehen.

Um ein einzelnes Signal (und damit auch die entsprechende CAN-Message) zum Senden zu markieren, wählen Sie den Menüeintrag

Verbinde "XYZ" (Signalname) mit einer neuen Variablen, zum SENDEN

im Kontext-Menü auf der Registerkarte CAN (per Doppelklick in die Signaltabelle, Spalte 'VarName').

Hintergrund-Information:: Bei der Auswahl eines Signals "zum Senden" wird das 'Transmit-Flag' ( "T" ) in der Signal-Definitions-Tabelle gesetzt, Spalte "Mapping".
Später, wenn Teile aus der CAN-Signal-Tabelle in Variablen umgesetzt werden, erhalten alle zu sendenden Variablen das Access-Attribut TX, was (aus Sicht des Terminals) 'Transmit', d.h. 'Senden', bedeutet.

Zum Senden markierte CAN-Telegramme (und die darin enthaltenen Signale) werden in der Baum-Ansicht rot markiert, und sind dadurch von den grün markierten 'normalen' Signalen (die aus Sicht des Anzeigeterminals nur empfangen aber niemals aktiv auf dem Bus gesendet werden) deutlich zu unterscheiden. Signale, die noch nicht mit einer Anzeige-Variablen verbunden wurden (und daher weder 'gesendet' noch 'empfangen' werden), sind in der Baumansicht wie im folgenden Beispiel grau markiert.

(Beispiel mit zum Senden und für den Empfang markierten Signalen;
Quelle: <Programmiertool>/programs/CdbSendT.cvt )

Leider enthält eine 'normale' CAN-Datenbasis (*.dbc) keine Informationen darüber, ob und wann ein CAN-Telegramm gesendet werden soll.
Als eine (etwas unbeholfene) Lösung dieses Problems gilt das folgende Prinzip:

Wenn für mindestens ein Signal (der Message) eine von Null verschiedene "Update Time" (hier: Sendezyklus in Millisekunden) auf der Registerkarte Variablen) definiert ist,
dann wird die Message periodisch gesendet, und zwar mit der niedrigsten "Update Time" die für alle in der Message enthaltenen Signale definiert wurde;
Haben alle in eine CAN-Message "gemappten" Signale das Update-Intervall Null, dann wird diese Message nicht periodisch gesendet (und zwar "schlicht und einfach" aus dem Grund, weil das Programm nicht weiss, mit welchem Sende-Intervall die Message gesendet werden sollte).
Stattdessen wird die Message immer dann gesendet, wenn sich beim 'Mappen' des Inhaltes (8-Byte Datenfeld der CAN-Message) etwas geändert hat.
(ähnlichkeiten mit dem PDO-Mapping von CANopen sind kein Zufall..);
Solange das globale Flag signals.tx_enable nicht gesetzt ist, wird keine 'CANdb-Message' gesendet (weder periodisch, noch ereignisgesteuert).
Das alte "ctx"-Kommando wird von diesem Flag allerdings nicht beeinflusst. Beispiel:
@signals.tx_enable = 1 : REM enable transmission of CAN signals
Bei neueren Geräten kann das gleiche Flag auch per Script gesteuert werden, z.B.:
CAN.tx_enable := 1; // REM enable transmission of CAN signals 'from database'

Der minimale Sendezyklus liegt bei 10 Millisekunden, d.h. maximale Frequenz 100 Hz. Die tatsächlich erreichbaren Zykluszeiten hängen natürlich von der Baudrate, Buslast, CPU-Geschwindigkeit und -Auslastung ab.

Beispiel zum Senden von 'CANdb'-Signalen

Ein Beispielprogramm zum Senden von CAN-Signalen finden Sie in der Datei programs/CdbSendT.cvt . Darin sind u.A. vier Variablen ("FourSines1" bis "FourSines4") mit CAN-Signalen verbunden, die periodisch gesendet werden. Um das Senden zu starten, drücken Sie den Softkey 'Transmission: DISABLED', so daß der Button-Text auf 'Transmission: ENABLED' umschaltet.
Drei weitere Variablen ("ThreeSines1" to "ThreeSines3") sind mit Signalen in einer anderen CAN-Message verbunden; diese wird mit einer anderen Intervallzeit gesendet (siehe Spalte "Update Time" in der Variablen-Definitions-Tabelle).

(Screenshot aus 'CdbSendT.cvt' - Beispielprogramm zum Senden von CAN-Signalen)

Auf der zweiten Seite des Testprogramms werden die gesendeten Signale wieder empfangen und angezeigt (Variablen "Rx4Sines1" to "Rx4Sines4"). Um diesen Test durchzuführen, benötigen Sie ein Gerät mit zwei CAN-Schnittstellen, wobei CAN1 hier zum Senden, und CAN2 zum Empfangen verwendet wird. Verbinden Sie beide Busse miteinander, starten die Sendung ("TX: ENABLED"), und beobachten die angezeigten Werte (numerisch oder im Y(t)-Diagram). Da die oben erwähnten Testsignale einen sinusförmigen Verlauf mit unterschiedlichen Frequenzen haben (per Event-Definition auf der aktuellen Seite erzeugt), sind die Werte gut voneinander zu unterscheiden, und CAN-'Aussetzer' gut zu erkennen.

Auf der vierten Seite des Testprogrammes wird demonstriert, wie per Interpreterkommando das zyklische Senden eines CAN-Signals (inkl. aller anderen Signale, die in der gleichen CAN-Message enthalten sind) zur Laufzeit umkonfiguriert werden kann.
Hier die ursprüngliche (aus der CAN-Datenbank importierte) Definition:

Zum Ändern der Zykluszeit wird, wie hier beschrieben, die Zykluszeit (<Variablenname>.cy) neu gesetzt:

      ThreeSines1.cy := 0;    // Turn off the periodic transmission of signal "ThreeSines1"
      ThreeSines1.cy := 300;  // Periodically transmit signal "ThreeSines1" every 300 milliseconds

(Quelle: Beispielprogramm ?/programs/CdbSendT.cvt, Seite 4)

Zur Erinnerung:

Bei Variablen, die mit (aus Sicht des MKT-Views) zu sendenden Signalen verbunden sind, wird bei Zykluszeit "Null" nur dann ein CAN-Telegramm gesendet, wenn sich bei der Zuweisung an die Variable der Wert ändert.
Der Sendezyklus gilt -strenggenommen- nicht für ein einzelnes CAN-Signal, sondern für die gesamte CAN-Message, in der wie im obigen Beispiel auch andere Signale enthalten sein könnten, die dann -prinzipbedingt- "mitgesendet" werden !

In einer realen Anwendung kann so z.B. selektiv das Senden von CAN-Telegrammen unterdrückt werden, abhängig vom Betriebszustand, der Buslast, oder der Gültigkeit bestimmter (berechneter) Werte.

Falls Ihnen keine geeignete Hardware zur Verfügung steht, können Sie die CAN-Sendungen notfalls mit dem Simulator im Programmiertool testen (gesendete Telegramme können auf der Registerkarte 'Errors / Messages' angezeigt werden). Die vom Simulator gesendeten Telegramme sind (ganz im Gegensatz zum 'echten' Terminal) zeitlich nicht sehr präzise, und die Sende-Intervalle sind auf ca.100 Millisekunden begrenzt. In der 'echten' Hardware besteht dieses Problem nicht, da dort ein Hardware-Timer in Verbindung mit einem Echtzeit-Kernel mit Taskwechselzeiten im Mikrosekundenbereich verwendet wird. Dies kann mit einem 'normalen' Windows-PC nicht emuliert werden.

Siehe auch (im Zusammenhang mit dem Senden von CAN / CAN FD - Botschaften):

CAN-Senden mit Hilfe des CAN Simulators im Programmiertool
CAN-Senden mit Hilfe des Logfile-Replay-Utilities im Programmiertool
CAN-Senden mit dem programmierbaren Terminal per Script

Zurück zur Übersicht

Anhang

Dieser Anhang enthält zusätzliche Informationen, die Sie im Normalbetrieb nicht brauchen. Es ist daher nicht unbedingt nötig, ihn durchzuarbeiten... lediglich den Haftungsausschluß sollten Sie unbedingt zur Kenntnis nehmen !

Strategie zur Belegung von CAN-Message-Objekten (bei alten Geräten mit 'FULL-CAN'-Controller)

Gilt nur für veraltete Geräte wie z.B. 'MKT-View Plus' !

Im Terminal wird ein sogenannter FULL-CAN-Controller verwendet. Bis zu 13 Hardware-Empfangs-Puffer dienen darin zum Empfang von CANdb-Messages. Jeder dieser Empfangspuffer (im folgenden "Empfänger" genannt) wird von der Firmware so konfiguriert, daß er genau EINEN BESTIMMTEN CAN-Identifier empfängt. Daher können pro CAN-Bus maximal 13 verschiedene (CANdb-)"Messages" vom Terminal empfangen werden.

Ein Problem des Terminals ist, daß die Applikation eventuell mehr CANdb-MESSAGES enthält als der FULL-CAN-Controller (zu einem bestimmten Zeitpunkt) empfangen kann. Die Firmware im Terminal versucht, dieses Problem mit der folgenden Strategie zu lösen:

Bei jeder Anzeigeseiten-Umschaltung wird zunächst getestet, welche Variablen "momentan" wirklich gebraucht werden. Jede Variable, die mit einem CAN-Signal verknüpft ist, und für die noch ein entsprechendes Message-Objekt vorhanden ist, wird ein neuer Empänger reserviert (meistens teilen sich mehrere Variablen einem Empänger, wenn die entsprachenden "Signale" mit der gleichen "Message" transportiert werden....)
Stellt sich dabei heraus, daß zu wenig Empfänger vorhanden sind, werden alle Empfänger für Signale von "alten Anzeigeseiten" freigegeben und Schritt 1 wiederholt.
Wenn nach Schritt 1 noch Empfänger frei sind, werden auch Empfänger für APERIODISCH übertragene Messages/Signale eingerichtet.
Wenn nach Schritt 2 noch weitere Empfänger frei sind, werden auch Empänger für momentan "nicht verwendete" Variablen/Signale/Messages konfiguriert, unabhängig von deren Übertragungszyklus.

Resultat: Die Wahrscheinlichkeit ist relativ hoch, daß bei einer Seitenumschaltung die Werte der anzuzeigenden Variablen bereits vorliegen bzw. "gültig" sind (weil die entsprechenden Signale bereits empfangen wurden).

Falls Ihre Anwendung weniger als 13 verschiedene CAN-Message empfangen muß, brauchen Sie sich um die Strategie nicht zu kümmern, bzw. keine Signale als "APERIODISCH" zu kennzeichnen, weil alle Variablen/Signale "immer" (zu jeder Zeit, unabhängig von der Anzeigeseite) angezeigt werden.
(Zur Erinnerung: Eine CANdb-"Message" enhält i.A. mehr als ein CANdb-"Signal", darum stehen die Chancen recht gut daß Ihre Anwendung weniger als 13 Messages pro Bus benötigt. Die Anzahl verwendeter(!) CANdb-MESSAGES wird auf der Registerkarte "CANdb" des Programmiertools für beide Busse angezeigt.

Unglücklicherweise liefert die importierte CANdb-Datei dem Programmiertool (noch?) keine Information ob eine Message periodisch, "häufig", oder "selten" gesendet wird. Darum können Sie dies auf der Seite "Variablen" als "UPDATE-TIME" (bei CANdb eher "Transmission Cycle") eintragen. Geben Sie ein "A" ein, um einer Variable das Attribut "aperiodisch übertragen" zu geben. Nach Klick auf "Apply" wird dies als "APERIODIC" angezeigt.

Nebenbei bemerkt, das "Terminal mit CAN-Signal-Anzeige" sollte ursprünglich keine Messages senden. Dies könnte sich in Zukunft ändern. Wenn dann auch Messages nach CANdb-Definition gesendet werden, stehen entsprechend weniger als 13 Hardware-Empfangsregister im CAN-Controller zur Verfügung. Um so wichtiger wird es dann sein, dass die oben beschriebene Strategie funktioniert, und die "aperiodischen" Messages als solche markiert sind.

Hintergrund-Info:: In den meisten Terminals ist die Verwendung eines interruptgetriebenen Empfangspuffers unmöglich. Es könnten viele tausend Messages pro Sekunde auftreten, zu viel für die im Terminal verwendete CPU. Lediglich bei Terminals mit integriertem CAN-Logger wird ein großer Puffer im RAM verwendet, um alle vom Anzeigeprogramm und CAN-Logger empfangenen CAN-Telegramme vor der weiteren Verarbeitung zwischenzuspeichern.

Warenzeichen, Haftungsausschluß, etc

( wird eines Tages von rechtskundiger Hand ins Deutsche übersetzt ;-)

Namings for products in this manual, that are registered trademarks, are not separately marked. The same applies to copyrighted material. Therefore the missing ®(r) or ©(c) does not implicate, that the naming is a free trade name. Furthermore the used names do not indicate patent rights or anything similar.

CANdb® is registered trademark of Vector Informatik GmbH
NTCAN API© is copyright by ESD electronic system design GmbH
PCAN Dongle and the PCAN API© is copyright by PEAK-Service GmbH
Microsoft, Windows, Win95, WinNT, WinXP® are registered trademarks of Microsoft Corporation
The 'SmallPort' utility was written by Alexander Weitzman

The software and accompanying written materials (including instructions for use) are provided "as is" without warranty of any kind. Further, MKT Systemtechnik does not warrant, guarantee, or make any representations regarding the use, or the results of the use, of the software or written materials in terms of correctness, accuracy, reliability, currentness, or otherwise.

The entire risk as to the results and performance of the software is assumed by Licensee and not by MKT Systemtechnik or its distributors, agents or employees.

THERE ARE NO OTHER WARRANTIES, EITHER EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE,
WITH RESPECT TO THE SOFTWARE, THE ACCOMPANYING
WRITTEN MATERIALS, AND ANY ACCOMPANYING HARDWARE.

MKT Systemtechnik
Haßkampstraße 75-77
32257 Bünde (Germany)

Phone: 05223/493933-0
Fax: 05223/493933-20

Web: http://www.MKT-Sys.de

Letzte Änderungen (Dokument-Revisions-Historie)

2021-01: Struktur dieses Dokumentes überarbeitet, Hinweise zum 'Neu-Laden' von CAN-Datenbanken ergänzt.
Weiterhin in einem sehr frühen 'Experimentalstadium': Import von *.arxml (neben *.dbc).
2020-02: Support für CAN FD, mit bis zu 64 Bytes im Datenfeld.
2015-06: Links und Textmarken für die Script-Sprache (CAN.DecodeMessage) ergänzt.
2011-06: Hinweise zu CAN-via-UDP ergänzt.
2011-01: Hinweise zum Senden von "CAN-Signalen" aus dem englischen Original übersetzt.
2009-10: Erste Ansätze zum Senden von CAN-Telegrammen mit Signaldefinitionen aus CANdb-Dateien (*.dbc)
2003-12: CAN-Handling wegen gemultiplexter Signale total umgeschrieben (nun mit interruptgetriebenem Ringpuffer)
2003-11: Signal-Timeout-Monitor eingebaut
2003-07: Option "Ignorieren von NODE- und MESSAGE-Namen" beim Vergleich neuer/alter Signale implementiert
2002-10: CANdb file import history, Strategie bei Belegung der FULL-CAN-Objekte
2002-09: Hinweis zu mehrfach definierten Signalen aufgenommen

zurück zur Übersicht