Migration des applications NI-CAN vers NI-XNET

Si vous commencez à écrire une nouvelle application en utilisant NI-XNET, vous n'avez pas besoin de la couche de compatibilité. Vous n'en avez besoin que si vous voulez utiliser des applications NI-CAN existantes avec des périphériques NI-XNET.

La bibliothèque de compatibilité supporte les périphériques et modules d'interface CAN et LIN. Il ne supporte pas les dispositifs et modules d'interface multiprotocole de véhicule, tels que les PCIe-8510, PXIe-8510 et NI 9860, qui nécessitent un câble émetteur-récepteur. Il ne supporte pas non plus les modules LIN de la Série C puisqu'il n'existe pas d'équivalent basé NI-CAN.

Pour que les applications existantes fonctionnent, les drivers NI-XNET et NI-CAN doivent être installés. Le paquet d'installation NI-XNET contient tous les composants nécessaires au fonctionnement de la bibliothèque de compatibilité. Reportez-vous à Installing the NI-XNET Compatibility Library for NI-CAN pour obtenir des instructions détaillées.

En général, l ' API NI-CAN est associée au matériel CAN hérité, y compris les interfaces CAN de la série 2. NI-XNET est le driver principal des interfaces NI-XNET CAN, LIN et FlexRay de nouvelle génération. Les nouvelles applications pour les interfaces NI-XNET utilisent le driver et l'API NI-XNET. 

Si vous avez une application existante qui utilise NI-CAN, NI fournit une bibliothèque de compatibilité pour vous aider à réutiliser ce code avec les interfaces NI-XNET CAN Série C, PCI et PXI plus récentes. Les fonctionnalités de la bibliothèque de compatibilité s'appliquent à l'API NI-CAN, pas à NI-XNET Reportez-vous au Manuel NI-CAN Hardware and Software pour en savoir plus sur les fonctionnalités de la bibliothèque de compatibilité.

Si votre application existante utilise NI-CAN et que vous avez l'intention d'utiliser désormais uniquement du matériel NI-XNET CAN de la Série C, PCI et PXI, vous voudrez peut-être faire passer votre code à NI-XNET. NI-XNET unifie de nombreux concepts de l'API NI-CAN antérieure, mais les fonctionnalités clés sont similaires. Le tableau suivant fait référence aux termes NI-CAN et aux termes NI-XNET analogues.

Remarque : Reportez-vous à Options de migration pour l'interface CAN USB-8472/73/76 pour en savoir plus.

Tableau 1. Conditions NI-CAN et conditions NI-XNET analogues

La figure suivante met en évidence la différence de numérotation entre NI-XNET et NI-CAN . Le haut "CAN0" correspond au nom du port NI-CAN pour utiliser le premier port de la carte PCI-8513. Vous pouvez utiliser ce même port avec l'API NI-XNET en utilisant CAN1. Vous pouvez renommer les ports NI-CAN pour qu'ils soient identiques à ceux de NI-XNET - cela ne pose aucun problème.

Figure 1. Différence de numérotation entre NI-XNET et NI-CAN

Remarque : Si la couche de compatibilité NI-CAN est installée, une interface NI-XNET apparaît deux fois dans NI Measurement & Automation Explorer (MAX). C'est normal car les deux drivers signalent la présence de la carte à MAX - une entrée concerne le lecteur NI-CAN, et l'autre NI-XNET.

La figure suivante montre une situation similaire, sauf qu'elle utilise une cible temps réel (RT). Les périphériques NI-XNET sont affichés sous la cible RT dans MAX, mais les périphériques NI-XNET utilisés par NI-CAN via la couche de compatibilité apparaissent uniquement sous l'outil Configuration du matériel NI-CAN RT. Vous pouvez voir que CAN1 dans NI-XNET est le même port que CAN0 sous NI-CAN .

Figure 2.  L'affichage des interfaces CAN à utiliser avec NI-XNET et la couche de compatibilité a une vue différente.

Pour ouvrir la fenêtre Configuration du matériel NI-CAN RT, lancez MAX et sélectionnez Outils » NI-CAN » Configuration du matériel RT, puis fournissez l'adresse IP de la cible RT.

Bien que la bibliothèque de compatibilité NI-XNET pour NI-CAN s'efforce d'assurer des fonctionnalités de base, vous ne pouvez pas toujours mapper complètement la bibliothèque de NI-CAN à NI-XNET en raison de fonctionnalités spécifiques au matériel ou de différences fondamentales dans la plate-forme NI-XNET.

Vous trouverez ci-dessous certaines des principales fonctions incompatibles ainsi que des solutions de contournement. Pour une liste plus complète, voir le Manuel NI-CAN Hardware and Software pour la version 2.7 ou ultérieure. 

1.  Réponse automatique aux trames distantes

Cette fonctionnalité est disponible sur le matériel NI-XNET ; cependant, la nouvelle architecture ne fournit pas un moyen de maintenir la compatibilité. Si votre application requiert cette fonctionnalité, vous devez mettre votre code à niveau pour utiliser l'API NI-XNET. Pour en savoir plus sur la manière de gérer les trames distantes avec l'API NI-XNET, consultez le Manuel du matériel et des logiciels NI-XNET. 

2.  Transcepteurs externes

Cette fonctionnalité est disponible sur certains de nos matériels NI-XNET. Les modèles PCI-8513 et PXI-8513 sont des exemples de matériel XNET pouvant éventuellement utiliser des câbles émetteur-récepteur externes.

3. Fréquence de la base de temps maître

Les interfaces NI-XNET détectent automatiquement la fréquence d'entrée de l'horloge et se synchronisent sans aucun paramètre de l'utilisateur. Comme ce processus est automatique, vous n'avez plus la possibilité de changer la fréquence de la base de temps maître. Les interfaces NI-XNET supportent différentes fréquences d'horloge pour la synchronisation (1 MHz, 10 MHz et 20 MHz) sans changer explicitement la base de temps maître. Les fréquences de 1 MHz et 10 MHz sont également disponibles à l'exportation.  

 4.  Enregistrement des erreurs de communication et des mises en garde

NI-XNET offre une nouvelle façon d'enregistrer les erreurs de bus. Au lieu d'enregistrer les trames CAN avec l'encodage d'état du bus, vous pouvez maintenant simplement lire l'état du bus :

Figure 3.  Les erreurs de bus peuvent maintenant être visualisées en observant l'état du bus.

Cette fonctionnalité est native de l'API NI-XNET; la compatibilité avec NI-CAN n'est pas possible.

5.  Format d'horodatage

NI-XNET n'utilise plus que le format d'horodatage absolu. Cependant, des fonctions sont disponibles pour obtenir un horodatage d'événements spécifiques. Avec ces horodatages, vous pouvez calculer le temps "relatif" à partir de différentes références sans avoir à récupérer les données dans un autre format.

Figure 4.  NI-XNET utilise les horodatages absolus, mais il existe encore des moyens d'obtenir des horodatages relatifs.

Si vous avez besoin de cette fonctionnalité, vous devez modifier votre code pour utiliser l'API NI-XNET.

6.  Transmission d'horodatage et récupération de timeline

Cette fonctionnalité n'était pas disponible dans NI-XNET 1.0 mais a été introduite dans NI-XNET 1.1. La fonctionnalité est maintenant appelée "CAN Replay".

Figure 5.  La configuration d'une relecture CAN peut se faire avec un flux de sortie de trame.

7.  Événements RTSI

NI-XNET dispose de fonctionnalités RTSI pour synchroniser une base de temps et un déclenchement de démarrage. Cependant, il n'est pas possible de configurer des événements (autrement dit, transmettre une trame CAN) sur une impulsion RTSI. Il n'est pas non plus possible de configurer des événements RTSI basés sur des événements CAN.

Vous devrez peut-être modifier votre application pour utiliser l'API NI-XNET pour diverses raisons. La section suivante décrit comment modifier votre code NI-CAN pour utiliser l'API NI-XNET.

Les informations suivantes sont destinées à vous aider à traduire des concepts familiers de NI-CAN à NI-XNET pour faciliter la transition de code. Il ne couvre pas toutes les applications possibles. Si vous avez besoin d'aide pour convertir une partie de votre code, contactez NI.

API de trame

Ouverture de l'interface

Les interfaces NI-CAN nécessitent une configuration avant de pouvoir les ouvrir. Dans NI-XNET, vous créez d'abord une session sur l'interface, puis vous pouvez utiliser des nœuds de propriété pour modifier n'importe quelles propriétés de la session. C'est le même modèle utilisé par de nombreuses autres API NI, y compris NI-DAQmx. 

Figure 6.  NI-XNET et NI-CAN configurent les propriétés du bus différemment.

Lecture de trames

La lecture des trames est similaire dans NI-CAN et NI-XNET :

Figure 7.  Le code nécessaire pour lire les trames dans les deux API est très similaire.

Avec l'augmentation des performances et la nouvelle architecture du moteur DMA piloté par le périphérique NI, vous n'avez pas besoin d'interroger le périphérique NI-XNET pour voir combien de trames sont disponibles. Cela était requis dans NI-CAN pour des raisons de performance. La fonctionnalité est toujours disponible dans NI-XNET mais n'est plus requise pour lire toutes les trames disponibles. (l'entrée -1 dans la fonction nxRead renvoie toutes les trames disponibles.)

Figure 8.  NI-XNET facilite la demande pour savoir combien de trames sont disponibles.

Le format de trame comporte des informations similaires dans NI-CAN et NI-XNET mais est présenté d'une manière légèrement différente:

Figure 9.  NI-CAN et NI-XNET contiennent des données de trame similaires dans chaque cluster.

Écriture d'une seule étape

Le VI nxWrite (Frame CAN).vi de NI-XNET utilise un tableau de trames comme entrée. Par conséquent, si vous voulez envoyer une seule étape, vous devez créer un tableau d'une étape.

Figure 10.  Pour envoyer des données de trame dans NI-XNET, un tableau de données doit être une entrée.

Écriture de plusieurs étapes

NI-XNET utilise la longueur du tableau pour savoir combien de trames écrire.

Figure 11.  Des appels de fonctions similaires sont disponibles dans NI-CAN et NI-XNET pour l'envoi de trames.

Écriture de trames périodiques

Dans NI-CAN, l'écriture de trames périodiques avec l'API Frame nécessite de configurer un objet pour chaque trame à envoyer ou à recevoir. Les interfaces CAN NI de série 2 ont une limite de 49 objets. 

Figure 12.  L'envoi d'une trame de période dans NI-CAN nécessite la configuration d'objets avec des appels de fonctions distincts.

La configuration de trames périodiques individuelles dans NI-XNET est légèrement différente. Avec une intégration NI-XNET étroite avec les bases de données de signaux et de trames, le moyen le plus simple de tirer parti des trames périodiques dans NI-XNET est d'utiliser un fichier de base de données FIBEX pour décrire les trames utilisées par le réseau. Lorsque vous utilisez la base de données FIBEX, le driver NI-XNET configure et gère automatiquement les trames périodiques sans interaction supplémentaire de l'application. 

Par exemple, envisagez de configurer une trame périodique (appelée "cyclique" dans NI-XNET) dans la base de données avec l'ID d'arbitrage, la longueur de charge et la période. Une fois configurée et enregistrée, l'application peut utiliser une session point par point pour transmettre ou recevoir cette trame. La commande d'E/S charge dynamiquement toutes les trames d'une base de données, ce qui facilite la sélection des trames dans l'application. Vous devez configurer un alias indiquant à NI-XNET quelle base de données utiliser pour que cette fonctionnalité fonctionne, ce qui est abordé dans la section suivante. 

Figure 13.  L'envoi de trames périodiques dans NI-XNET peut être considérablement simplifié.

Lors de l'ouverture d'une session, le driver NI-XNET lit tous les paramètres de la base de données. Il configure ensuite une transmission et/ou réception cyclique dans le driver et le Firmware NI-XNET. Depuis l'application, vous mettez simplement à jour la valeur, et NI-XNET transmet automatiquement la valeur la plus récente au cours du cycle suivant. NI-XNET propose également des sessions File d'attente, que vous pouvez utiliser pour mettre en file d'attente de nombreuses valeurs.

L'avantage principal de l'utilisation de bases de données de signaux est la maintenabilité du code. La mise à jour de la base de données met automatiquement à jour le code, ce qui ne nécessite aucun changement de code pour suivre les changements dans l'ID d'arbitrage, les vitesses de transmission, les définitions de bits, etc. Si vous voulez changer un paramètre, vous pouvez simplement changer le fichier de base de données. Aucune modification n'est nécessaire dans le code.

NI-XNET fournit des fonctions permettant de modifier par programmation les valeurs chargées à partir du fichier de base de données. Cela ne change pas les valeurs réelles écrites dans votre fichier de base de données - uniquement les valeurs chargées par le driver NI-XNET à l'exécution.

Figure 14.  Les fonctions de bas niveau peuvent être utilisées pour configurer dans NI-XNET l'envoi de trames périodiques.

Si vous ne voulez pas avoir de fichier de base de données et que vous voulez tout définir à l'exécution, vous pouvez aussi créer une base de données "en mémoire". De cette façon, vous pouvez développer toute une configuration réseau par programmation et l'utiliser dans votre application. Vous pouvez consulter l’exemple CAN Dynamic Database Creation.vi situé à Aide»Recherche d’exemplessous Entrées et sorties matérielles»CAN»NI-XNET»Bases de données (édition et gestion).

Autres fonctions de l'API Frame

De nombreux exemples d'API NI-CAN Frame ont des exemples NI-XNET similaires.  

API de voie 

Édition d'un fichier de base de données

Vous pouvez choisir entre deux techniques principales pour éditer un fichier de base de données : avant ou pendant l'exécution. Pour éditer un fichier de base de données avant son exécution dans NI-CAN, l'éditeur de base de données dans MAX est requis. NI-XNET déplace toutes les modifications de base de données dans un éditeur de base de données autonome. Vous pouvez lancer l'éditeur de base de données à partir de Démarrer»Tous les programmes»National Instruments»NI-XNET Database Editor.

Figure 15.  NI-XNET Database Editor est un outil autonome permettant d'éditer des bases de données CAN.

Pour en savoir plus sur NI-XNET Database Editor, consultez l ' Introduction à FIBEX et le white paper NI-XNET Database Editor.

NI-XNET propose des fonctions permettant d'éditer un fichier de base de données FIBEX par programmation. Vous pouvez utiliser ces fonctions pour créer des outils de manipulation de base de données personnalisés dans votre application. Consultez les exemples fournis avec le logiciel NI LabVIEW en allant dans Aide»Recherche d'exemples et en naviguant vers Entrées et sorties matérielles»CAN»NI-XNET»Bases de données (édition et gestion).

Entrée et sortie point par point

Dans NI-CAN, vous devez pointer votre application vers le fichier .DBC ou .NCL de votre disque dur. Dans NI-XNET, vous devez d'abord ajouter un alias au fichier de base de données (.DBC, .NCL ou FIBEX .xml) avant d'exécuter l'application. Vous pouvez y parvenir de plusieurs manières différentes. Vous pouvez ouvrir l'exemple nommé CAN Signal Input Single Point.vi situé sous Hardware Input and Output»CAN»NI-XNET»Intro to Sessions»Signal Sessions. Cliquez avec le bouton droit sur la liste de signaux et allez à Parcourir le fichier de base de données pour sélectionner votre fichier de base de données sur le disque. Le driver NI-XNET crée automatiquement un alias pour cette base de données afin que vous puissiez facilement la sélectionner à nouveau.

Figure 16.  Sélectionner une base de données dans NI-XNET permet de la référencer dans une application.

La commande d'E/S NI-XNET lit alors automatiquement votre fichier de base de données et remplit tous les noms de signaux. Cela facilite le choix du signal à utiliser dans votre application.

Figure 17.  La commande se met automatiquement à jour avec les signaux disponibles dans la base de données.

L'image suivante compare les diagrammes pour l'écriture de signaux/voies point par point NI-CAN et NI-XNET. La lecture est similaire et les deux drivers présentent des exemples. 

Figure 18.  NI-CAN et NI-XNET envoient des données point par point de manière similaire.

Signal en entrée et en sortie

La lecture et l'écriture de données waveform sont également similaires dans NI-CAN et NI-XNET, et chaque driver propose des exemples de comparaison.

Figure 19.  La lecture et l'écriture de waveforms sont similaires dans les deux API.

Une différence est que NI-XNET utilise une fréquence d'échantillonnage par défaut de 1000. Vous pouvez facilement changer la fréquence d'échantillonnage en utilisant un nœud de propriété.

Figure 20.  La fréquence de rééchantillonnage d'une waveform peut être configurée avec une propriété.

Résumé

Tableau 2.  Ce tableau montre les différences fondamentales entre les fréquences d'échantillonnage NI-CAN et NI-XNET pour les communications CAN.

Lecture de la base de données sur le disque

Dans NI-CAN, vous pouvez utiliser une base de données directement sur le disque. Dans NI-XNET, vous créez généralement manuellement un alias pour ce fichier afin de pouvoir utiliser la commande d'E/S NI-XNET dans votre application. Cependant, si vous distribuez votre application ou si vous voulez émuler le comportement NI-CAN, vous pouvez créer par programmation un alias de base de données pour un fichier sur le disque. Pour ce faire, consultez l'exemple Managing Local Databases.vi situé sous Hardware Input and Output»CAN»NI-XNET»Databases (Editing and Managing).

La couche de compatibilité NI-XNET pour NI-CAN simplifie considérablement la transition du code NI-CAN pour tirer parti des interfaces NI-XNET CAN et FlexRay de nouvelle génération. Malgré des différences mineures, la plupart des applications NI-CAN fonctionnent avec peu ou pas de modification sur le matériel NI-XNET lorsqu'elles sont utilisées avec la couche de compatibilité. 

• Options de migration pour l'interface CAN USB-8472/73/76
• Présentation de la plate-forme NI-XNET CAN, LIN et FlexRay
• NI-CAN Hardware and Software Manual
• Explorer les options de remplacement du matériel pris en charge par NI-CAN de NI