Migrieren von NI-CAN-Anwendungen auf NI-XNET

Überblick

Die Serie NI-XNET von CAN-, LIN- und FlexRay-Schnittstellen ist eine Kombination schneller CAN-, LIN- und FlexRay-Schnittstellen mit der Treibersoftware NI-XNET. NI-XNET-Schnittstellen bieten im Hinblick auf Leistung, einfache Bedienbarkeit und langfristige Unterstützung zahlreiche Vorteile gegenüber älteren CAN-Produkten wie etwa PCI/PXI/PCMCIA-Schnittstellen der Serie 2.

Inhalt

Um diese Leistungssteigerung für CAN-, LIN- und FlexRay-Schnittstellen mit NI-XNET bereitzustellen, hat NI eine neue API für NI-XNET-Produkte entwickelt. NI ist sich der großen installierten Anwendungsbasis bewusst, die in der älteren NI-CAN-API geschrieben wurde, und der Notwendigkeit, diese Anwendungen langfristig zu pflegen.

 

Um den Übergang von Anwendungen, die für NI-CAN geschrieben wurden, zu NI-XNET zu erleichtern und um von den neuen Funktionen der NI-XNET-Schnittstellen zu profitieren, enthält der NI-XNET-Treiber eine NI-CAN-Kompatibilitätsebene, die NI-CAN-Funktionsaufrufe auf Treiberebene emuliert. Da dieser Funktionsumfang auf Treiberebene installiert wird, sind für die meisten mit NI-CAN geschriebenen Anwendungen nur wenige Anpassungen erforderlich, um NI-XNET sofort nutzen zu können. Bei der Umstellung auf NI-XNET-Schnittstellen sind einige Unterschiede zwischen den beiden Treibern zu beachten.

 

Dieser Artikel erklärt, wie Sie die NI-CAN-Kompatibilitätsbibliothek verwenden, um NI-CAN-Anwendungen mit neuer NI-XNET-Hardware zu implementieren. Dabei werden potenzielle Kompatibilitätsprobleme erläutert und es wird beschrieben, wie vertraute NI-CAN-Konzepte auf die NI-XNET-API übertragen werden können.

 

Weitere Informationen zu den Grundlagen der CAN-Kanal-APIs von NI finden Sie unter Die NI-CAN-Kanal-API.

Installation der Unterstützung für die Kompatibilitätsbibliothek

Wird eine neue Anwendung mit NI-XNET geschrieben, ist keine Kompatibilitätsschicht nötig. Sie ist nur erforderlich, wenn bestehende NI-CAN-Anwendungen mit NI-XNET-Geräten eingesetzt werden sollen.

Die Kompatibilitätsbibliothek unterstützt CAN- und LIN-Schnittstellengeräte und -Module. Sie unterstützt keine Multiprotokoll-Schnittstellengeräte und -Module wie PCIe-8510, PXIe-8510 und NI 9860, für die ein Transceiverkabel erforderlich ist. Ebenso wenig werden LIN-Module der C-Serie unterstützt, da es kein NI-CAN-basiertes Äquivalent gibt.

Damit bestehende Anwendungen funktionieren, muss der Treiber NI-XNET zusätzlich zum NI-CAN-Treiber installiert sein. Das Installationspaket NI-XNET enthält alle nötigen Komponenten für die Kompatibilitätsbibliothek. Ausführliche Anweisungen finden Sie unter Installieren der NI-XNET-Kompatibilitätsbibliothek für NI-CAN.

NI-CAN

Im Allgemeinen wird die NI-CAN-API mit älterer CAN-Hardware verwendet, darunter die Familie der CAN-Schnittstellen der Serie 2. NI-XNET ist der Treiber für die NI-XNET-CAN- und -FlexRay-Schnittstellen der nächsten Generation. Neue Anwendungen für NI-XNET-Schnittstellen verwenden den NI-XNET-Treiber und die API. 

Kompatibilität

Wenn Sie über eine vorhandene Anwendung verfügen, die NI-CAN verwendet, bietet NI eine Kompatibilitätsbibliothek, mit deren Hilfe Sie diesen Code mit neueren Schnittstellen der XNET-CAN-C-Serie, PCI und PXI wiederverwenden können. Die Funktionen der Kompatibilitätsbibliothek gelten für die NI-CAN-API und nicht für NI-XNET. Weitere Informationen zu den Funktionen der Kompatibilitätsbibliothek finden Sie im NI-CAN-Hardware- and Softwarehandbuch.

Übergang

Wenn Ihre vorhandene Anwendung NI-CAN verwendet und Sie beabsichtigen, ab sofort nur noch NI-XNET-CAN-C-Serie-, PCI und PXI-Hardware zu verwenden, möchten Sie Ihren Code möglicherweise auf NI-XNET umstellen. NI-XNET vereint viele Konzepte der früheren NI-CAN-API, wobei die Schlüsselfunktionen ähnlich sind. Die folgende Tabelle enthält Querverweise auf NI-CAN-Begriffe und analoge NI-XNET-Begriffe.

Hinweis: Weitere Informationen finden Sie unter Migrationsoptionen für USB-8472/73/76-CAN-Schnittstellen.

NI-CAN-BegriffNI-XNET-BegriffKommentieren
CANdb-DateiDatenbankNI-XNET unterstützt mehr Datenbankdateiformate als die NI-CAN-Kanal-API, FIBEX, .DBC und .NCD.
NachrichtFrame„Frame“ ist der Branchenbegriff für die Bits, die über den Bus übertragen werden. Dieser Begriff wird in Standards wie CAN und FlexRay verwendet.
KanalSignalDer in der Industrie gängige Begriff „Signal“ kommt in Standards wie FIBEX vor.
Kanal-API-TaskSitzung (Signal-I/O)Anders als NI-CAN unterstützt NI-XNET die gleichzeitige Verwendung von Kanal-I/O (Signal) und Frame-I/O.
Frame-API-CAN
Objekt (Queue-
Länge null)
Session (Frame-I/O-Single-Point)Das CAN-Objekt in NI-CAN bietet Eingang (Lesen) und Ausgang (Schreiben) in einem Objekt. NI-XNET verfügt zur besseren Steuerung über ein separates Objekt für jede Richtung. Ist die Queue-Länge von NI-CAN für eine Richtung Null, entspricht das unter NI-XNET dem Frame I/O Single-Point.
Frame-API-CAN
Objekt (Queue-
Länge ungleich Null)
Sitzung (Frame-I/O in Warteschlange eingereiht)Ist die Queue-Länge von NI-CAN für eine Richtung nicht gleich Null, entspricht das unter NI-XNET dem Frame I/O Queued.
Frame-API
Netzwerkschnittstelle
Objekt
Sitzung (Frame-I/O-Stream)Das Netzwerkschnittstellenobjekt in NI-CAN bietet Eingang (Lesen) und Ausgang (Schreiben) in einem Objekt. NI-XNET bietet zur besseren Steuerung für jede Richtung ein anderes Objekt.
Schnittstelle*SchnittstelleBei NI-CAN beginnen die Schnittstellennamen bei CAN0, bei NI-XNET jedoch bei CAN1 (oder FlexRay1).
PeriodischZyklischNI-CAN verwendet den Begriff „periodisch“, doch Datenbank-Editor und Eigenschaftsknoten unter NI-XNET sprechen von „zyklisch“.

Tabelle 1: NI-CAN-Begriffe und analoge NI-XNET-Begriffe

In der folgenden Abbildung wird der Unterschied bei der Nummerierung zwischen NI-XNET und NI-CAN dargestellt. „CAN0“ ganz oben entspricht dem Namen der NI-CAN-Schnittstelle, die die erste Schnittstelle der PCI-8513-Karte nutzt. Dieselbe Schnittstelle kann mithilfe von CAN1 mit der NI-XNET-API verwendet werden. Die Namen der NI-CAN-Schnittstellen können denen der NI-XNET-Schnittstellen angeglichen werden, sodass Probleme vermieden werden.

Abbildung 1: Nummerierungsunterschied zwischen NI-XNET und NI-CAN

Hinweis: Wenn die NI-CAN-Kompatibilitätsschicht installiert ist, wird eine NI-XNET-Schnittstelle zweimal im NI Measurement & Automation Explorer (MAX) angezeigt. Das ist normal, da beide Treiber das Vorhandensein der Karte an MAX übermitteln: Ein Eintrag ist für das NI-CAN-Laufwerk, der andere für NI-XNET.

Die nachfolgende Abbildung zeigt eine ähnliche Situation, außer dass ein Real-Time-Zielsystem verwendet wird. NI-XNET-Geräte werden in MAX unter dem Real-Time-Zielsystem angezeigt, aber die NI-XNET-Geräte, die NI-CAN über die Kompatibilitätsschicht verwendet, werden nur im NI-CAN-RT-Hardwarekonfigurationstool angezeigt. Sie können sehen, dass CAN1 in NI-XNET die gleiche Schnittstelle ist wie CAN0 unter NI-CAN.

Abbildung 2:  CAN-Schnittstellen für den Einsatz mit NI-XNET und die Kompatibilitätsschicht werden in unterschiedlichen Ansichten angezeigt.

Um das Fenster NI-CAN-RT-Hardwarekonfiguration zu öffnen, starten Sie MAX und wählen Sie Tools » NI-CAN » RT-Hardwarekonfiguration, und geben Sie dann die IP-Adresse für das Real-Time-Zielsystem an.

Inkompatibler Code

Ziel der NI-XNET-Kompatibilitätsbibliothek für NI-CAN ist zwar, einen grundlegenden Funktionsumfang zu gewährleisten, jedoch kann diese aufgrund von hardwarespezifischen Eigenschaften oder Kernunterschieden in der NI-XNET-Plattform nicht immer vollständig von NI-CAN auf NI-XNET abgebildet werden.

Im Folgenden sind einige der wichtigsten inkompatiblen Funktionen zusammen mit Abhilfemaßnahmen aufgeführt. Eine vollständigere Liste finden Sie im NI-CAN Hardware- and Softwarehandbuch für Version 2.7 (oder neuer). 

1.  Automatische Antwort an dezentrale Frames

Diese Funktion ist auf NI-XNET-Hardware verfügbar. Die neue Architektur bietet jedoch keine Möglichkeit, die Kompatibilität aufrechtzuerhalten. Wird diese Funktion für eine Anwendung benötigt, muss der Programmcode für die Verwendung der NI-XNET-API aktualisiert werden. Weitere Informationen zur Verarbeitung von Remote-Frames mit der NI-XNET-API finden Sie im NI-XNET-Hardware- and Softwarehandbuch

2.  Externe Sende-Empfangs-Geräte

Diese Funktion ist auf einigen unserer NI-XNET-Hardwaregeräten verfügbar. Die Modelle PCI-8513 und PXI-8513 sind Beispiele für XNET-Hardware, die optional externe Sende-Empfangs-Geräte verwenden kann.

3. Rate der Master-Zeitbasis

NI-XNET-Schnittstellen erkennen automatisch die Takteingangsfrequenz und synchronisieren sich dazu ohne Parameter vom Benutzer. Da dieser Prozess automatisch abläuft, kann die Rate der Master-Zeitbasis nicht mehr verändert werden. NI-XNET-Schnittstellen unterstützen verschiedene Taktraten für die Synchronisation (1 MHz, 10 MHz, 20 MHz), ohne dass die Zeitbasis des Masters ausdrücklich geändert wird. Außerdem werden die Zeitbasen 1 und 10 MHz zum Exportieren zur Verfügung gestellt.  

 4.  Protokollierung von Kommunikationsfehlern und -warnungen

NI-XNET bietet eine neue Methode, um Busfehler zu protokollieren. Anstatt CAN-Frames mit der Busstatuscodierung zu protokollieren, können Sie jetzt einfach den Busstatus lesen:


Abbildung 3:  Busfehler können nun durch Beobachten des Buszustands angezeigt werden.

Diese Funktion ist nativ in der NI-XNET-API enthalten; eine Kompatibilität mit NI-CAN ist nicht möglich.

5.  Zeitstempelformat

NI-XNET nutzt jetzt nur das Format des absoluten Zeitstempels. Jedoch stehen Funktionen für einen Zeitstempel spezifischer Ereignisse zur Verfügung. Mit diesen Zeitstempeln können Sie die „relative“ Zeit aus verschiedenen Referenzen berechnen, ohne Daten in einem anderen Format erneut erfassen zu müssen.


Abbildung 4:  NI-XNET verwendet die absoluten Zeitstempel, aber es gibt dennoch Möglichkeiten, relative Zeitstempel zu erhalten.

Wenn Sie diese Funktion benötigen, müssen Sie Ihren Code ändern, um die NI-XNET-API zu verwenden.

6.  Übertragung der Zeitstempel und Wiederherstellung der Zeitachse

Diese Funktion stand für NI-XNET 1.0 nicht zur Verfügung, wurde aber in NI-XNET 1.1 eingeführt. Diese Funktion heißt jetzt „CAN Replay“.

Abbildung 5:  CAN Replays können mit einem Frame-Ausgabe-Stream konfiguriert werden.

7.  RTSI-Ereignisse

NI-XNET umfasst RTSI-Komponenten für die Synchronisation einer Zeitbasis und eines Start-Triggers. Es ist allerdings nicht möglich, einen RTSI-Impuls zu nutzen, um Ereignisse zu konfigurieren (also einen CAN-Frame zu übertragen). RTSI-Ereignisse können auch nicht auf Basis von CAN-Ereignissen konfiguriert werden.

Umstellung von NI-CAN auf NI-XNET

Es gibt verschiedene Gründe, warum eine Anwendung für die NI-XNET-API angepasst werden sollte. Der nächste Abschnitt beschreibt, wie Sie Ihren NI-CAN-Code ändern, um die NI-XNET-API zu verwenden.

Die folgenden Informationen sollen Ihnen dabei helfen, vertraute Konzepte von NI-CAN in NI-XNET zu übersetzen und den Programmcodeübergang zu erleichtern. Nicht jede mögliche Anwendung wird hier geschildert. Wenn Sie Hilfe beim Konvertieren eines Programmabschnitts benötigen, wenden Sie sich an NI.

Frame-API

Öffnen der Schnittstelle

NI-CAN-Schnittstellen müssen konfiguriert werden, bevor sie geöffnet werden können. Unter NI-XNET wird zunächst eine Sitzung an der Schnittstelle erstellt, um anschließend die Eigenschaften der Sitzung mittels Eigenschaftsknoten zu verändern. Das gleiche Modell wird bei vielen anderen APIs von NI, einschließlich NI-DAQmx, genutzt. 

Abbildung 6:  Die Konfiguration der Buseigenschaften erfolgt in NI-XNET anders als in NI-CAN.

Lesen der Frames

Das Lesen der Frames geht in NI-CAN und NI-XNET ähnlich vonstatten:


Abbildung 7:  Der zum Lesen von Frames in beiden APIs benötigte Programmcode ist sehr ähnlich.

Dank der gesteigerten Leistung und der neuen gerätegesteuerten DMA-Engine-Architektur von NI müssen Sie das NI-XNET-Gerät nicht mehr abfragen, um zu sehen, wie viele Frames verfügbar sind. Bei NI-CAN war dies aufgrund der Leistung der Geräte nötig. Die Funktion ist weiterhin in NI-XNET verfügbar, ist aber nicht mehr zum Lesen aller verfügbaren Frames erforderlich. (Der -1-Eingang der nxRead-Funktion gibt alle verfügbaren Frames aus.)

Abbildung 8:  Mit NI-XNET können Sie einfacher abfragen, wie viele Frames verfügbar sind.

Das Frame-Format umfasst in NI-CAN und NI-XNET ähnliche Informationen, wird aber etwas anders dargestellt:

Abbildung 9:  Jeder Cluster für NI-CAN und NI-XNET enthält ähnliche Frame-Daten.

Schreiben eines einzelnen Frames

Das nxWrite (Frame CAN).vi in NI-XNET nutzt ein Array aus Frames als Eingang. Deshalb muss ein Array mit einem Frame erstellt werden, wenn ein einzelner Frame übertragen werden soll.

Abbildung 10:  Das Senden von Frame-Daten in NI-XNET erfordert ein Daten-Array als Eingang.

Schreiben mehrerer Frames

NI-XNET verwendet die Array-Länge, um zu ermitteln, wie viele Frames geschrieben werden müssen.

Abbildung 11:  Ähnliche Funktionsaufrufe sind in NI-CAN und NI-XNET für das Senden von Frames verfügbar.

Schreiben periodischer Frames

Unter NI-CAN muss zum Schreiben periodischer Frames mit der Frame-API ein Objekt für jeden zu übertragenden oder zu empfangenden Frame konfiguriert werden. NI-CAN-Schnittstellen der Serie 2 sind auf 49 Objekte begrenzt. 

Abbildung 12:  Das Senden eines periodischen Frames in NI-CAN erfordert die Konfiguration von Objekten mit separaten Funktionsaufrufen.

Das Konfigurieren einzelner periodischer Frames in NI-XNET läuft etwas anders ab. Bei einer engen NI-XNET-Integration mit Signal- und Framedatenbanken können periodische Frames in NI-XNET am einfachsten genutzt werden, indem eine FIBEX-Datenbankdatei zur Beschreibung der vom Netzwerk verwendeten Frames verwendet wird. Beim Einsatz der FIBEX-Datenbank konfiguriert und verarbeitet der NI-XNET-Treiber die Frames automatisch und ohne dass eine Interaktion seitens der Anwendung nötig ist. 

So wird ein periodischer Frame (in NI-XNET als „zyklisch“ bezeichnet) in der Datenbank mit Frame-ID, Nutzdatenlänge und Periode konfiguriert. Einmal konfiguriert und gespeichert, kann die Anwendung eine Einzelwertsitzung verwenden, um diesen Frame zu senden oder zu empfangen. Das I/O-Bedienelement lädt alle Frames dynamisch aus einer Datenbank, was die Auswahl der Frames in der Anwendung erleichtert. Damit dies funktioniert, muss ein Alias konfiguriert werden, der dem NI-XNET-Treiber mitteilt, welche Datenbank genutzt werden soll. Wie das geht, wird im nächsten Abschnitt erläutert. 

Abbildung 13:  Das Senden periodischer Frames in NI-XNET kann erheblich vereinfacht werden.

Wird eine Sitzung geöffnet, liest der NI-XNET-Treiber alle Einstellungen aus der Datenbank. Er konfiguriert dann ein zyklisches Senden und/oder Empfangen im Treiber und in der NI-XNET-Firmware. Aus der Anwendung wird der Wert einfach aktualisiert und NI-XNET überträgt beim nächsten Zyklus automatisch den neuesten Wert. NI-XNET umfasst auch Queued-Sitzungen, die dazu dienen, viele Werte in eine Queue abzulegen.

Der Hauptvorteil von Signaldatenbanken ist die Wartungsfreundlichkeit des Programmcodes. Durch die Aktualisierung der Datenbank wird der Code automatisch aktualisiert, sodass keine Code-Änderungen erforderlich sind, um Änderungen der Frame-ID, Übertragungsraten, Bit-Definitionen usw. zu verfolgen. Soll ein Parameter geändert werden, wird die Änderung einfach in der Datenbankdatei vorgenommen. Der Programmcode selbst bleibt unverändert.

NI-XNET bietet Funktionen zur Änderung der programmatisch aus der Datenbankdatei geladenen Werte. Dies ändert nicht die tatsächlich in die Datenbankdatei geschriebenen Werte, lediglich die durch den NI-XNET-Treiber während der Ausführung geladenen.

Abbildung 14:  Mit Low-Level-Funktionen kann das Senden periodischer Frames in NI-XNET konfiguriert werden.

Wenn keine Datenbankdatei erwünscht ist und alles während der Ausführung eingestellt werden soll, kann auch eine Datenbank „im Speicher“ erstellt werden. So lässt sich eine gesamte Netzwerkkonfiguration programmatisch erstellen und in einer Anwendung verwenden. Das Beispiel CAN Dynamic Database Creation.vi befindet sich in Hilfe » Beispiele suchen unter Hardware-Ein- und Ausgang » CAN » NI-XNET » Datenbanken (Bearbeiten und Verwalten).

Andere Frame-API-Funktionen

Viele Beispiele der Frame-API unter NI-CAN haben ähnliche Gegenstücke in NI-XNET.  

Kanal-API 

Bearbeiten einer Datenbankdatei

Zum Bearbeiten einer Datenbankdatei stehen zwei Hauptverfahren zur Auswahl: vor oder während der Ausführung. Um eine Datenbankdatei vor der Ausführung in NI-CAN zu bearbeiten, ist der Datenbankeditor in MAX nötig. NI-XNET verlagert die gesamte Datenbankbearbeitung in einen eigenständigen Datenbankeditor. Sie können den Datenbankeditor mit Start » Alle Programme » National Instruments » NI-XNET-Datenbankeditor aufrufen.

Abbildung 15:  Der NI-XNET-Datenbankeditor ist ein eigenständiges Tool zum Bearbeiten von CAN-Datenbanken.

Weitere Informationen zum NI-XNET-Datenbankeditor finden Sie im Whitepaper Einführung in FIBEX und den NI-XNET-Datenbankeditor.

NI-XNET bietet Funktionen zur programmatischen Bearbeitung einer FIBEX-Datenbankdatei. Diese können herangezogen werden, um benutzerdefinierte Tools zur Datenbankbearbeitung in eine Anwendung einzubinden. Die mit NI LabVIEW gelieferten Beispiele finden Sie unter Hilfe » Beispiele suchen und dann unter Hardware-Ein- und Ausgang » CAN » NI-XNET » Datenbanken (Bearbeiten und Verwalten).

Einzelwertein- und -ausgang

In NI-CAN müssen Sie Ihre Anwendung auf die .DBC- oder .NCL-Datei auf Ihrer Festplatte verweisen. In NI-XNET muss der Datenbankdatei erst ein Alias hinzugefügt werden (.DBC, .NCL oder FIBEX.xml), bevor die Anwendung ausgeführt wird. Dies kann auf verschiedene Arten geschehen. Das Beispiel CAN Signal Input Single Point.vi befindet sich unter Hardware-Ein- und Ausgang » CAN » NI-XNET » Einführung in Sitzungen » Signalsitzungen. Klicken Sie mit der rechten Maustaste auf die Signalliste und wählen Sie „Nach Datenbankdatei suchen“, um Ihre Datenbankdatei auf dem Datenträger auszuwählen. Der NI-XNET-Treiber erstellt automatisch einen Alias für diese Datenbank, so dass sie problemlos wieder ausgewählt werden kann.

Abbildung 16:  Durch Auswählen einer Datenbank in NI-XNET kann in einer Anwendung darauf zurückgegriffen werden.

Das NI-XNET-I/O-Bedienelement liest dann automatisch Ihre Datenbankdatei und füllt alle Signalnamen auf. So lässt sich ein Signal für Ihre Anwendung ganz einfach auswählen.

Abbildung 17:  Das Bedienelement wird automatisch mit den in der Datenbank verfügbaren Signalen aktualisiert.

Hier sehen Sie einen Vergleich der Blockdiagramme für das Schreiben von Einzelwertkanälen/-signalen in NI-CAN und NI-XNET. Das Lesen geht ganz ähnlich vonstatten und es gibt Beispiele für beide Treiber. 

Abbildung 18:  Das Senden von Einzelwertdaten ist bei NI-CAN und NI-XNET vergleichbar.

Signalverlaufseingang und -ausgang

Das Lesen und Schreiben von Signalverlaufsdaten ist in NI-CAN und NI-XNET sehr ähnlich. Zum Vergleich stehen in beiden Treibern Beispiele zur Verfügung.

Abbildung 19:  Das Lesen und Schreiben von Signalverläufen ist in beiden APIs vergleichbar.

Ein Unterschied besteht darin, dass NI-XNET eine Standard-Sample-Rate von 1000 verwendet. Sie können die Sample-Rate einfach mit Hilfe eines Eigenschaftsknotens ändern.

Abbildung 20:  Die Resample-Rate eines Signalverlaufs kann mit einer Eigenschaft konfiguriert werden.

Zusammenfassung

 

NI-CAN-Modus

NI-CAN SampleRateNI-XNET-ModusNotizen
Eingang0Signaleingang, Einzelwertk. A. (keine zusätzlichen Eigenschaften)
Eingang>0Signaleingang, SignalverlaufVerwenden Sie NI-CAN SampleRate, um die Eigenschaft Sitzung » Resample-Rate festzulegen.
Ausgang0Signalausgabe, XYSetzen Sie für jeden Frame mit Hilfe der NI-XNET-Datenbank-API CAN » Timing-Typ auf Ereignisdaten und CAN » Übertragungszeit auf null (kein Entprellen).
Ausgang>0Signalausgang, SignalverlaufStellen Sie für jeden Frame mit Hilfe der NI-XNET-Datenbank-API CAN » Timing-Typ auf Zyklische Daten und CAN » Übertragungszeit auf NI-CAN 1/SampleRate ein.
Ausgabe/Letzte>0Signalausgang, EinzelwertStellen Sie für jeden Frame mit Hilfe der NI-XNET-Datenbank-API CAN » Timing-Typ auf Zyklische Daten und CAN » Übertragungszeit auf NI-CAN 1/Sample-Rate ein.
Zeitstempel-Eingabek. A.Eingangssignal, XYk. A. (keine zusätzlichen Eigenschaften)

 

Tabelle 2.  Diese Tabelle zeigt die grundlegenden Unterschiede zwischen den Sample-Raten von NI-CAN und NI-XNET für die CAN-Kommunikation.

Lesen der Datenbank von der Festplatte

Unter NI-CAN kann die Datenbank direkt auf der Festplatte genutzt werden. In NI-XNET erstellen Sie normalerweise manuell einen Alias zu dieser Datei, damit Sie das NI-XNET-I/O-Bedienelement in Ihrer Anwendung verwenden können. Wird die Anwendung jedoch verteilt oder soll das Verhalten von NI-CAN emuliert werden, kann ein Datenbank-Alias für eine Datei auf der Festplatte auch programmatisch erstellt werden. Wie das geht, beschreibt das Lernbeispiel „Managing Local Databases.vi“ unter Hardware-Ein- und Ausgang » CAN » NI-XNET » Datenbanken (Bearbeiten und Verwalten).

NI-XNET-Kompatibilitätsschicht vereinfacht den Übergang

Die NI-XNET-Kompatibilitätsschicht für NI-CAN vereinfacht die Umstellung des NI-CAN-Codes erheblich, so dass dieser auch von modernen NI-XNET-CAN- und -FlexRay-Schnittstellen profitieren kann. Trotz kleiner Unterschiede funktionieren die meisten NI-CAN-Anwendungen ohne oder mit nur wenigen Änderungen mit der NI-XNET-Hardware, wenn sie mit der Kompatibilitätsschicht eingesetzt werden. 

Was this information helpful?

Yes

No