9860

[noir_desir_fab]

Bonjour tout le monde,

Suite à une erreur commerciale, j'ai eu une carte ni 9860 pour compact rio pour contrôler mes appareils  en can open, hors celle-ci n'est pas directement compatible canopen à condition de modifier le fpga (j'ai heureusement.le module fpga). 

Quelqu'un aurait déjà implémenté cette prog? 

cordialement Fabien  

[amaury74]

Bonjour Fabien,

J'ai eu fait une implémentation du CANOpen sur PC utilisant un adaptateur CAN-USB (https://www.fischl.de/usbtin/), malheureusement je n'ai plus le code :-(. Le secret est de bien formater les trames CANOpen, ce qui est très bien détaillé dans la spécification.

En outre, il est nécessaire de savoir quels protocoles sont requis : SDO (échange asynchrones dans une table adressée), PDO (échanges synchrones), NMT (timing), ...

La norme est complète et accessible : 

https://www.can-cia.org/can-knowledge/sdo-protocol

https://www.can-cia.org/can-knowledge/pdo-protocol

https://www.can-cia.org/can-knowledge/network-management

S'il est possible de se cantonner au SDO et au NMT, une implémentation partielle est assez simple. La gestion du PDO nécessite de gérer un mécanisme d’envoi périodique temps réel, ce que le FPGA permet de faire également.

[amaury74]

Bonjour Fabien,

Je crois que ma première réponse a été mangée par le forum.

Bref, je recommence. J'ai déjà implémenté le protocole CANOpen sur PC avec du matériel USB-CAN tiers.

Le secret est de bien formater les trames CANOpen. La spécification est très bien faite à ce sujet. J'ai retrouvé un bout de code que j'avais écrit pour tourner sur Raspberry Pi avec LINX, j'essaie de le remettre au net avant de le poster.

Quelques liens utiles :

https://www.can-cia.org/can-knowledge/sdo-protocol

https://www.can-cia.org/can-knowledge/pdo-protocol

https://www.can-cia.org/can-knowledge/network-management

Il est important de savoir s'il est nécessaire d'implémenter le PDO (communication synchrone) ou si le SDO (communication asynchrone) est suffisant.

[amaury74]

Pour ce qu'elle vaut, voici l'implémentation que j'avais réalisée pour Raspberry Pi. Il est nécessaire de reprendre la couche de communication bas niveau. Cependant, il est possible de conserver l'encodage sur l'hôte et de descendre uniquement la communication CAN sur le FPGA. Cela simplifiera la mise au point, quitte à tout descendre dans le FPGA à terme.

[noir_desir_fab]

Merci beaucoup je vais regarder en détail :).

Si quelqu'un l'a déjà implémenté dans un fpga (je crois qu'ils ne sont pas compatible avec la prog objet)

[Loïc_fr]

Bonjour,

Si si on peut faire de l'objet sur FPGA, il y a des restriction comme pas de dynamic dispacth.

Pour l'avoir fait moi même et  -> https://youtu.be/R71rjrFB1Oc?si=M4yTn-phLtNQnjax (41 minutes)

Apres je sais pas si les lib en question seront compatibles.

Loïc

[amaury74]

Effectivement, la couche objets que j'ai implémentée est prévue pour la partie hôte. Elle constitue un driver, à l'instar de DAQmx. Par contre, il est possible d'intégrer la FPGA Interface à la place de la couche CAN Socket et de mettre juste la communication CAN dans le FPGA.

[amaury74]

Quelque chose dans ce goût-là :

Après, pour la communication hôte<->FPGA, c'est selon les besoins : FIFO DMA ou contrôles en face avant. L'idée sous-jacente est que CAN_FPGA.lvclass peut être substituée par n'importe quelle autre classe d'abstraction matérielle : j'avais fait CanSocket, mais on peut imaginer CAN_XNET ou autre... Ainsi le code reste le même mais peut supporter plusieurs matériels.

[noir_desir_fab]

Merci beaucoup. 

Je vais essayer de voir pour l'implémenter du coup. 

[noir_desir_fab]

La couche basse de ton drivers est contenu dans ta biblio unix ?