Premiers pas avec Linuxcnc et règle de mesure

[Bruno26]

Bonjour à tous,
Après avoir déjà bien bricolé avec mes machines numérisées, une fraiseuse Crouzet FC100 et un tour Celtic 12 avec Mach3 je me décide à passer à Linuxcnc notamment pour profiter de ce que Linuxcnc peut faire avec des règles de mesure (encodeur à quadrature).
Mes machines sont numérisées à moindres coup, des PaP pas très gros, une Breakout board de base (http://www.omc-stepperonline.com/5-...face-for-stepper-motor-driver-stv2-p-197.html) et des drivers à quelques euros à peine.
Dans un premier temps je ne veux installer qu'une règle sur mon tour, sur le chariot transversal, là où j'ai le plus besoin de précision.
Je n'ai aucune expérience avec Linux non plus.
Pour l'instant j'ai juste réussi à installer Linuxcnc et à faire tourner 3 moteurs PaP. Jusque là, c'est pas plus difficile qu'avec Mach3.
Par contre, pour paramétrer les signaux A et B de ma règle, je comprend plus rien.
J'ai parcouru en autre ce document:
http://linuxcnc.org/docs/html/hal/rtcomps.html
mais je ne comprend rien à la syntaxe qu'il faut respecter et à quel paramètre correspond le numéro de pin sur le port //. Si j'ai bien compris, mais je n'en suis pas sûr du tout, il faut écrire dans le fichier ma-machine.hal?
Dans stepconf il y a comme choix pour les entrées du port // "entrée numérique" 0, 1,2 et3. Est-ce ça que l'on doit utiliser?
Si quelqu'un avait un exemple de config avec un encodeur autre que celui de la broche (que je rajouterai certainement plus tard) cela m'aiderai beaucoup.

A+

 

[vax]

D'autres vont te confirmer ça je pense, mais pour moi, tu ne peux pas lire une règle sur un port parallèle...

J'ai une petite chinoise numérisée avec des pas à pas et une cartes sur port //, mais mes machines qui utilisent des servos avec codeurs ou des règles) sont toutes ave des cartes MESA (5i20 et 7i33).
Codeurs en quadrature pour le tour, servos et règles Renishaw (directement en RS422) pour les machines 3 axes.

 

[Bruno26]

Aïe! Vu le prix des cartes Mesa, j'aimerai autant m'en passer, surtout que je n'ai pas besoin de beaucoup d'entrées.
J'ai peut-être un exemple intéressant ici:
https://forum.linuxcnc.org/38-gener...for-linear-encoder-and-stepper-motor?start=10
avec les fichiers ini et hal que je vais tenter d'éplucher pour y piquer ce qui m'intéresse.
Merci et à+.

 

[vax]

Je ne sais pas comment il utilise sa règle, il parle d'un seul signal...
J'avais vu cette manière d'utiliser une règle...

Au plaisir de te lire pour me coucher moins c.. un de ces jours prochain (j'espère pour toi )

 

[bendu73]

Sur ma machine, les règles Heidenhain sont branchées sur des boitiers ( EXE ). Ces derniers "transforment" le signal et ensuite il passe sur les entrées encoder de ma carte Mesa.

 

[Charly 57]

Bonjour
Je vais suivre ce sujet
Merci

 

[Bruno26]

Salut,
Ca ne marche pas encore mais je suis sur la bonne voie.
Pour l'instant en ayant rajouté les quelques lignes dans le fichier .hal comme dans l'exemple trouvé sur le forum linuxcnc, avec un inter sur une entrée de ma petite carte j'arrive à faire varier l'état de la variable encoder.0.phase-A (et B). Par contre avec ma règle ça ne marche pas mais le pb est juste électrique. Sur chaque entrée de la carte il y a un optocoupleur, ma règle est alimentée par le 5V du PC (qui tombe d'ailleurs à 4.70 quand je branche la règle) mais l'optocoupleur par l'alimentation 24V qui alimente les moteurs.
En écrivant ça je me dis, mais bien sûr, le but de cette carte est aussi d'isoler électriquement le PC du reste de la machine!
Bon, la règle, j'ai vérifier au multimètre, elle fonctionne bien.
Il faut donc que je bidouille ma carte au niveau des optocoupleurs et ça devrait le faire.
Il restera encore à ce que Linuxcnc affiche bien ce qui vient du module "encoder" de Linuxcnc.
Avec les cartes Mesa ou autre vous utilisez aussi les variables encoder.0.phase-A ou la carte Mesa renvoie directement l'info de position?

A+

 

[Bruno26]

Re salut,

Je viens d'installer Linuxcnc sur un autre PC un peu meilleur que celui que j'avais. En démarrant Linuxcnc pour la première fois je me suis un peu plus attardé sur le choix des configs proposées. Il y a en une qui correspond pas mal à ce que je veux faire à ceci près quelle utilise des servos commandés avec un PWM. Mais au niveau des encoders il y a tout ce qu'il faut. Cette config est by_interface.parport.etch-servo. Il y a bien les infos des encoders en entrée sur un port // et si j'ai bien compris pour afficher sur les visus la position mesurée il fallait que je rajoute dans ma config:
net Xpos-fb <= encoder.0.position
net Xpos-fb => axis.0.motor-pos-fb

A+

 

[Charly 57]

Bonjour

Alors tu en es à la phase d'essai en réel.
Est ce que ça donne satisfaction ?

 

[Bruno26]

Euh, je n'ai pas eu le temps de faire mes petites soudures sur ma carte. Je vous tiendrai au courant de mes essais.
D'ailleurs, est-ce gênant que la règle soit alimentée par le 5v du pc?

 

[Bruno26]

Yes! Ca marche! J'ai bien la position lue par la règle en visu.
Il me restera à calibrer tout ça, et j'espère bien pouvoir utiliser la boucle fermée avec le moteur PaP et cette règle.
J'ai configuré Linuxcnc pour mon tour, savez-vous comment je peux enlever l'affichage du rayon et n'avoir que celui du diamètre, me connaissant c'est une source d'erreur.
C'est bon, j'adore, j'adopte définitivement Linuxcnc!
Il faut aussi que je refasse plus proprement toute l'installation de l'électronique dans un boitier métallique. Je pense utiliser comme boitier... une bonne vieille boite aux lettres, de celles qui sont étroites pour être mise à la verticale.

A+

 

[Charly 57]

Yes! Ca marche! J'ai bien la position lue par la règle en visu.
Il me restera à calibrer tout ça, et j'espère bien pouvoir utiliser la boucle fermée avec le moteur PaP et cette règle. A+

Super et de plus en plus intéressant le coup de la boucle fermée.
Je lis tes posts avec attention

 

[Bruno26]

Merci Charly pour ton intérêt.
La boucle ouverte est réglée. Par contre j'ai dû limiter la vitesse du moteur sinon à cause de la latence du PC je perds des infos venant de la règle. J'ai BASE_PERIODE à 20000 et le chariot se déplace à 420mm/min. Il faut dire que la règle a une résolution de 1µm, ça fait beaucoup d'infos par mm à ne pas rater. Oui, je sais, je n'ai pas besoin de 1µm de précision sur ma pièce, mais en tournage j'ai parfois besoin (ou envie) du 1/100 en diamètre, ce qui ne fait que 5µm sur le déplacement du chariot. La résolution doit forcément être inférieure à la précision voulue, surtout pour la boucle fermée.
Pour vérifier que la règle ne raconte pas n'importe quoi j'ai utilisé un comparateur. Après des mouvements rapides dans tous les sens, je reviens à la position où j'avais mis le comparateur à zéro et je compare avec l'info de la règle.
En boucle ouverte, le positionnement se fait déjà avec à peu près 1/100 d'écart. La boucle fermée ne sera utile que pour ce dernier petit centième. Pour m'y atteler, il faut déjà que je potasse la doc...

A+

 

[gaston48]

Bonjour,
C'est ton port // qui limite la fréquence d'entrée du codeur d'ou l’intérêt d'un système Mesa
dont le FPGA assure le comptage. Le traitement de la position est calculé ensuite par des boucles
en servo-thread entre 1 et 3 Khz en fonction de la vitesse du noyaux temps réel de ton PC.
Il n'y a que la Beaglebone black et son Linuxcnc qui s'appelle Machinekit qui dispose d'entrée / sortie
très rapides grâce, à non pas un FPGA, mais à ses PRU.
Il faut quand même adapter une carte fille spécifique, "un CAPE" au beaglebone comme la Furaday
ou la faire soi-même .
Pour gérer ta boucle fermée, tu vas rentrer le composant PID.
Il va piloter le step/dir en mode vitesse, c'est prévu dans le composant "stepgen".
La PID va gérer une consigne et une information retour, sous la forme d'une "position".
La position est un terme en flottant, qui est le résultat du comptage en terme entier issu du codeur
multiplié (ou diviser) par un coefficient d'échelle.

 

[Bruno26]

Il y a sans doute une limite de fréquence du port//, mais je ne doit pas encore y être. En passant BASE_PERIODE de 50000 à 20000 j'ai pu multiplier par 2 la vitesse de déplacement sans perdre d'infos de la règle. Si j'oublie la règle je peux multiplier encore la vitesse par 2.
J'ai un peu galère et pas tout compris aux différentes affectation de "pins" dans le fichier Hal, mais je crois que j'ai fini par trouver un réglage Tip-top!
Je n'ai pas fait comme tu as écrit gaston. Vu que la boucle ouverte marche déjà pas mal, je trouve dommage de piloter les Pap en vitesse. J'ai essayé, mais c'est pas terrible.
Avec un pap, si on lui demande de bouger d'1mm, il va le faire le plus vite possible avec la précision de la mécanique. Comme pré-positionnement, on ne peut pas faire mieux.
Du coup, dans le PID, j'ai utilisé surtout le terme FF0. En mettant ce terme à 1 et tout le reste à 0, on retrouve exactement la boucle ouverte. Le reste, c'est à dire les derniers pouillèmes, c'est le terme intégral qui le fait.
Vu que j'ai 3 dixièmes de backlash sur le transversal de mon tour, j'ai en fait mis FF0 à 0.985 pour ne pas dépasser la consigne et Pgain à 0.15 pour compléter. Avec Igain à 10, j'ai un positionnement très rapide avec une bande morte à ....2.5microns! Je n'ai pas rentré de valeur de backlash dans le fichier ini, mais le système sans fou, c'est aussi rapide et précis même en changeant de sens.
Je suis super content, c'est génial Linux. Je vais avoir envie de mettre aussi une règle sur le trainard et sur ma fraiseuse!

J'essayerai de faire une copie d'écran avec Halscope en imposants quelques déplacements rapides.
Je posterai aussi mes fichiers ini et Hal, qui sont un peu brouillons, je découvre à peine Linuxcnc.
J'essayerai d'autre chose aussi avec Linuxcnc, comme utiliser un brushless d'avion de 500W pour en faire un servo sur l'axe vertical de ma fraiseuse qui pour l'instant est bien lent avec un Pap pas très puissant.
A+

 

[gaston48]

Du coup, dans le PID, j'ai utilisé surtout le terme FF0. En mettant ce terme à 1 et tout le reste à 0, on retrouve exactement la boucle ouverte. Le reste, c'est à dire les derniers pouillèmes, c'est le terme intégral qui le fait.

pourquoi pas , ton raisonnement se tient, mais l'action intégrale est a utiliser avec parcimonie
elle agit avec du retard avec pour conséquence un dépassement à l'arrivé à la consigne.
C'est bien uniquement pour du positionnement précis en laissant du temps pour la stabilisation,
mais ça dégrade complètement les performances dynamiques, comme un suivi précis de trajectoire.
C'est comme un four, tu va bien atteindre et réguler précisement une consigne apres une stabilisation,
mais en aucune façon tu pourras envoyer et respecter une courbe de monté en température précise.
Dans une chaîne d'asservissement classique de CNC avec servomoteur, ils sont commandés en vitesse
en +/- 10 V par exemple qui est la dérivé des positions successives souhaitées
Pour ton pas à pas au lieu d’être piloté en +/- 10 V, il l'est par une fréquence variable ce qui revient au
même, l’intérêt est qu'il n'a pas besoin de tachymétrie comme sur un servomoteur DC
car c'est un moteur synchrone

 

[rentemplan]

Bonsoir @Bruno26

Existe t'il un topic sur la numérisation de ton celtic 12

Envoyé de mon SM-A320FL en utilisant Tapatalk

 

[Charly 57]

Bonsoir Bruno
Quelle marque et type de règle as tu utilisé ?
Merci

 

[Bruno26]

Bonsoir @Bruno26

Existe t'il un topic sur la numérisation de ton celtic 12

Envoyé de mon SM-A320FL en utilisant Tapatalk

Eh non , pas de topic sur la numérisation de mon tour, mais en résumé:
Jusqu'à maintenant c'est resté du très simple et pas cher. J'avais commencé en remplaçant que les verniers du petit chariot et du transversal par des Nema23 (2.8Nm) réductés 1/2 par courroies crantées. Drivers de bases:http://www.ebay.com/itm/1-Axis-Cont...-Driver-Board-CNC-Router-Single-/200976756349
Bob de base aussi:
http://eu.stepperonline.com/5-axis-...face-for-stepper-motor-driver-stv2-p-197.html
Avec une alim 24v 9A, Mach3, et les vis trapézoïdales d'origines passablement usées.
Je suis quand même arrivé à faire ce que je voulais, c'est à dire mon premier moteur 4 temps de 17cc.
Ensuite j'ai rajouté un variateur triphasé pour le moteur de broche, piloté par Mach3.
Plus récemment j'ai "numérisé" la vis mère pour déplacer le trainard, car avec le petit chariot j'avais du mal à faire autre chose qu'un cône. Avec le même moteur mais réducté 1/4 et les 2 demi-écrous d'origine. Backlash énorme mais en tournage ça ne m'a pas géné.
Et dernièrement j'ai installé ma règle (http://www.machine-dro.co.uk/gs300-220-standard-glass-scale-220mm-reading-length-1-micron.html) sur le côté du transversal. Le petit chariot génait pour l'installer et comme il ne servait plus à grand chose je l'ai viré et remplacé par un gros bloc d'acier que j'ai fait 5mm moins haut pour pouvoir utiliser plus facilement certains gros outils.
Et bien sûr Linuxcnc pour pouvoir utiliser la règle au mieux.

Pour en revenir à ma règle, j'ai fait encore quelques essais. Au moment du changement de sens j'arrive à une erreur maxi de 0.1mm vite rattrapée pour un backlash de 0.3mm. Quand la vitesse est constante l'erreur est au plus de 2/100. L'erreur descend à 2 ou 3µm en 0.5s.
J'ai essayé d'utilisé le parametre BACKLASH dans le fichier ini, mais ça délire complet. En fait je crois que Linuxcnc n'est pas prévu pour une boucle fermée avec une règle et du backlash. La valeur affichée dans axis n'est pas la valeur lue par l'encoder mais estimée/corrigée par la valeur du backlash. Linuxcnc ne capte pas que l'encoder est bien en fin de chaine et non pas sur le moteur. D'ailleurs je n'ai pas trouvé à quelle variable la position affichée correspond.

Mais j'ai quand même un doute sur le port //. Avec une vitesse de 7mm/s, donc une fréquence des infos de la règle de 7kHz, il devrait déjà y avoir de la marge avec base_period à 50000ns (=20kHz). Or, j'ai dû le descendre à 20000ns pour que ça marche mais là c'est Linuxcnc qui me dit de temps en temps que c'est trop juste pour le PC.
J'ai essayé aussi de secouer le chariot à la main sans toucher à la commande et là l'info de position de la règle dérive (toujours en vérifiant avec un comparateur). Peut-être qu'en bougeant le chariot à la main, même sur les seulements 0.3mm de backlash j'arrive à dépasser la vitesse de 7mm/s?
Bref, encore des essais et vérifs à faire, mais je commence à lorgner du côté des cartes Mesa...

Oups, j'ai été un peu bavard à cette heure tardive!

A+

 

[gaston48]

Le backlash de ini, c'est une correction apportée par le planificateur de trajectoire,
donc c'est rajouté à la consigne et va à l'encontre de la mesure (sans jeux) de la règle.
En revanche un jeux dans une boucle d’asservissement, c'est un élément non linéaire
dans le fonction de transfert, comme des frottements, un stickslip, c'est une source d'instabilité
supplémentaire (comme le retard du I) qui oblige à prendre plus de marge de gain.
Si tu évolues vers un asservissement plus classique, donc avec essentiellement du P
n'oublie pas de boucler dans la PID les paramètres vitesses soit:
encoder.N.velocity vers pid.N.feedback-deriv

Un PC homogène est un PC avec un temps de latence dans les 5000 ns et un clock
de processeur dans les 3 G Suivant le nombre de voies, on peut tourner avec
une servo-period de 250000 ns (opération en flottant) la base_period est plus dépendante
du port I/O. Il faut gérer aussi les sorties Step/dir avec un facteur microstepping très élevé
pour se rapprocher d'un moteur "continu".
Avec Mesa, on n'indique même plus la base_period, c'est géré par le FPGA.

Concernant Mesa, pas évident de faire un choix, surtout si on souhaite quelque chose
d'évolutif. Dans ce cadre là, je privilégie plutôt les cartes avec port 50 pins, elles ont l'avantage
d'avoir des I/O non multiplexées, ce qui laisse la possibilité de bidouiller des cartes filles simples
soi même (les I/O du fpga sont en 3.3V).
Dans le très haut débit de bus pcie, je pense à une 6i24-25 par exemple.
après le pcie vient le port ethernet avec la 7i80HD, puis // avec la 7i90HD mais
je pense qu'il faut définitivement éliminer le port //.

http://eusurplus.com/index.php?route=product/category&path=63

 

[Bruno26]

J'avoue que même après avoir passé du temps à lire des docs de linuxcnc, j'ai du mal à voir le lien exact entre "temps de latence" , "max jitter", et "base_period". il faut mettre base_period à 25000ns + max jitter, avec une peu de marge? Dans mon cas, max jitter= 7380ns (sur la ligne base thread)
Je vais potasser les variables que tu m'as indiqué.
Je trouve dommage la gestion du backlash par linuxcnc.
Il fut un temps où je travaillais pour l'automobile et notamment sur l'asservissement du papillon de gaz motorisé. Pour éviter que le papillon reste dans une position quelconque en cas de défaut, il y avait 2 ressorts assez puissant qui ramenaient le papillon dans une position où il est juste possible de trainer la voiture jusqu'au garage le plus proche. Un peu comme le manche d'une radio commande de modélisme avec le retour au neutre dès qu'on sache le manche. Comme non-linéarité c'était terrible. En plus des termes classiques d'un pid il y avait une pré-commande (une tension appliquée au moteur) pour compenser l'effort des ressorts qui changeait donc de sens dès que le papillon dépassait cette position de repos. Certes, changer le sens de la tension ne prend quasi pas de temps, contrairement à la compensation du backlash, mais il fallait vraiment zoomer fort autour de cette position de repos pour voir une erreur de l'asservissement.

Mince, j'ai laisser tourner le test de latence pendant que j'écrivais ce message sur un autre PC et max jitter est passé à 12600. Peut-être juste à cause de l'écran de veille?

ouais, c'est peut être pas très fiable ma règle avec une résolution de 1 micron et le port parallèle...
je commence à regarder celle-là qui est quand même abordable:
http://store.mesanet.com/index.php?route=product/product&product_id=55

A+ et merci pour votre aide.

 

[Bruno26]

Bon, c'est bien juste l'écran de veille qui fait exploser max jitter.

 

[gaston48]

je commence à regarder celle-là qui est quand même abordable:

Oui elle est abordable seule, malheureusement il n'y a pas de mystère, la solution DB25 passe par un multipléxage à travers
cette connectique avec l'obligation de rajouter de grosses cartes filles dédiées qui sont très chères.
C'est plus une solution puissante plug and play
L'autre famille de carte est à 3 connecteurs 50 pins pour nappe. Comme les pins sont nombreuses, elles se
passent de multiplexage ce qui entraîne une plus grande simplicité des cartes filles.
Il existe donc une famille "db25" et une "50 pins" avec des ports communiquant avec le PC plus ou moins rapide
qui vont limiter le servo_period, du pcie à l'antique port //.
Il faut voir de près ces DB25, tout n'est pas multiplexé , la 7i92 revendique le fait de simuler le DB25 port
// avec des cartes break ou board qu'on trouve partout.
Tout depend du firmware qui est flashé, et il y en a une ribambelle. (Les 2 ancienne cartes 5i20 et 5i23 le firmware
est chargé quand tu lance linuxcnc.) Sur le forum Linuxcnc Peter wallace "PCW" la patron de Mesa est toujours là
pour renseigner...
http://eusurplus.com/index.php?route=product/product&path=63_292&product_id=657

 

[rentemplan]

@Bruno26 merci pour ce complément d'information, pour ma part j'ai lu avec intérêt tes bavardises tardives, vue que je suis entrain de rassembler les éléments pour numériser un tour socomo de 90 EP car sur ce tour la boite d'avance a été cannibalisée il me manque tous les pignons du premier étage de la boite ainsi que les pignons de la lyre d'où le dilemme numérisastion/reconstruction de la boite d'avance.
sans vouloir abusé ni interférer dans ce poste as tu la possibilité de mettre quelques photos de cette transformation.

 

[Bruno26]

Effectivement la 7i92 est au même prix, mais pas en stock.
Pour la 5i25, il y a pourtant écrit "that uses standard parallel port pinouts and connectors for compatibilty with most parallel port interfaced motion control / CNC breakout cards". Ca veut bien dire compatible avec les bob de base prévue pour fonctionner avec un port //?
D'ailleurs elle n'a "que" 34 I/O. Edit: Ah oui, 34 I/O mais 50 pins répartis sur 2 connecteurs.
J'avoue que je me sens un peu perdu avec toutes ces cartes existantes!

rentemplan, je te ferai quelques photos, mais il faut d'abord que je range un peu mon bazar et que je remonte le Pap du trainard. En fait, j'ai numérisé le tour et la fraiseuse avec le même matériel (moteurs et électronique). Ca me prends environ 5 minutes pour démonter et remonter les moteurs d'une machine à l'autre... Pareil pour le variateur triphasé qui peut alimenter les 2, c'est une prise murale qui en sort. J'avais lu qu'il fallait absolument le minimum de connectique entre le variateur et le moteur, mais ça n'a jamais posé de problème. Sur ma fraiseuse j'ai même laisser les contacteurs qui permettent de changer de sens ou de vitesse "électrique" (moteur dahlander 2 vitesses).

A+

 

[gaston48]

la 7i92M est en stock (chez l'importateur portugais aussi qui est tout aussi concurrentiel en prix si on compte
le transport et la douane en cas d'achat au state).
Oui 34 I/O c'est bien pour ça qu'il y multiplexage concernant la lecture des codeurs par exemple pour la
carte fille 7i77.
Elle peut simuler 2 port // sans doutes, mais j'ai parcouru vite fait les fichiers de mappage de pins des firmwares
existants, dans tous les cas, je ne vois que 2 entrées codeur directes possibles, une brassée de step/dir ... une paire de PWM ou une liaison série
qui permet dans la carte fille qu'on branche, de démultiplier les GPIO

 

[Bruno26]

Autant pour moi, c'est la 7i92 sans le "M" qui n'est pas en stock chez l'importateur!

 

[Bruno26]

Bon, ben va falloir que je me décide...
Si la 7i92M peut avoir 2 entrées codeur directes possible, dans un premier temps ça me suffira, ma règle sur le transversal plus un codeur de broche (que je n'ai pas encore).
Y a t'il une différence sur la facilité d'utilisation/configuration entre les cartes sur port PCI et celles ethernet? J'ai bien l'impression que tu es plus adepte de la 7i92M.
A+

 

[gaston48]

'ai bien l'impression que tu es plus adepte de la 7i92M.

Non, j'aime autant le PCI et tant qu'à faire une carte à connecteurs 50 pins ... J'ai une ancienne 5i20.
Au sujet de la 5i25, chez Mesa, tu download le package de doc et firmware et dans le dossier hostmot2
tu as une ribambelle de fichiers .bit à flasher et des fichiers .pin correspondant qui décrive le mappage des pins de la 5i25.
en fonction des cartes filles que tu va brancher.
Pour les autres cartes les fichiers .pin ne sont pas toujours présents, il me semble qu'on les obtient à partir
des fichier .bit avec une ligne de commande en console ?

edit ...
ici:
https://forum.linuxcnc.org/27-driver-boards/31210-need-firmware-for-chinese-bob-on-mesa-7i92


le firmware dmmbob par exemple, me semble générique.
hostmot2 est le gros composant que tu va charger dans hal , à la place du composant de gestion de port //
et qui va gérer la carte Mesa. Les composants isolés utilisé précédemment comme stepgen, encoder etc sont maintenant
intégrés dans hostmot2, avec la même syntaxe de paramétrage et de branchement, il y a juste le préfixe qui
fait référence à la carte mesa.
Attention quand tu vas utilisé la 5i25 directement, tu n'as aucune protection des sorties, surtension, inversion etc
c'est direct le FPGA en 3.3 V.
Le minimum serait ça, qui est uniquement composé de composants passifs avec des diodes:
http://store.mesanet.com/index.php?route=product/product&path=83_87&product_id=118
mais qui fait son prix aussi ... la connectique tout ça ...
Faudrait au moins intercaler des buffers - level translator, style 4050 sur une plaque CI à trous

 

[Bruno26]

Merci encore pour ton aide Gaston. Bon c'était pas vraiment prévu au départ mais la 5i25 est commandée.
Le plus dur reste à faire pour apprendre comment configurer la carte avec ma bob de base...
A+