Je roule en NVEM !

Pour info:
Mon problème de commandes "sautées" semble venir sur les commandes de type "M" comme M3/M4/M5. Cela se confirme avec les macros que j'utilise beaucoup et qui sont du type M200, M300 etc.
Pareil. Seule solution: ajouter des tempos, même minimes.

Bonjour
La doc mach3 parle de synchronisation des axes (pour faire du suivi d’arête par exemple) mais je n'ai rien trouvé dans les commandes ou la config qui permette de la faire.
Je ne parle pas ici de synchro des moteurs lorsqu'il y a deux moteur pour un axe.

Jacques

Bonjour
Voila les infos trouvées. En fait les commandes G0 ou G1 font automatiquement de la "co-ordinated linear motion", il faut dans ce cas que les axes soient sur la meme ligne de commande par exemple G1 x1 y2 z3.
Il faut donc effectivement attendre que la commande soit terminée pour passer a la suivante. Quand on fait un sleep(1000) par ex ca laisse suffisamment de temps pour que la commande se termine. J'ai vu dans d'autre macros que les commandes suivantes sont utilisées pour optimiser le temps d'attente:

While Ismoving()
sleep (100)
Wend

La boucle s'executera autant de fois que nécessaire jusqu’à la fin de l'execution de la commande précédente.
J'essaierais
Jacques

Salut,

Oui, c'est ça, et c'est ce qui complique un peu la programmation en VB sous Mach3 (la plupart des codes M sont écris en Visual Basic Script) ; en fait le programme VB s’exécute en // du programme en GCode, l'un n'attend pas l'autre. (exécution sur des threads différents)

le code suivant

While Ismoving()
sleep (100)
Wend

signifie:

Tant qu'au moins un axe bouge (While Ismoving() )
faire une pause de 100 ms (pour laisser du temps au autres processus windows pour bosser)
Retour au début de la boucle.

tant que la fonction IsMoving() retourne "vrai" (un axe au moins est en train de bouger), la boucle s'effectuera. Le sleep() n'est pas indispensable, mais reste préférable pour éviter de faire tourner un processus à plein rendement pour rien, la pause de 100ms dans la boucle permet au CPU de faire plein d'autres choses en attendant que les 100ms soient écoulées et qu'il aille vérifier de nouveau si les axes bougent encore (il ne faut pas oublier que Windows est un système multitâches, il ne faut pas consommer des ressources dont d'autres processus ont besoin inutilement)

@gipet: j'avoue que je n'avais pas compris (et pas fait attention) que les commandes qui s'exécutaient en même temps étaient des M, c'est donc tout à fait normal.

Sur ton bout de GCode, ce sont des commandes M3 M5, donc marche/arrêt broche ; le M/A broche peut être temporisé dans les réglages de broche, ça évite d'avoir des tempo à ajouter dans le code et ça permet à la broche d'atteindre sa V maxi avant de commencer à usiner par exemple.



cadre général parameters

CW delay Spin Up ; ici 1.5s ; ça veux dire que la commande qui sera exécutée après le M3 ne le sera qu'après 1.5s (en rotation horaire)

CW delay Spin DOWN ; même chose pour le M5, le mouvement ne se fera qu’après le délais demandé.

Ce délais peut être en seconde ou en ms, ça dépend du réglage de la config générale ; paramètre 04 dwell in ms  s'il est coché, il faudra donner la valeur de tempo en ms (1s = 1000 ms) ; attention: dans la fenêtre, le libellé est toujours: "Secondes", même si réglé en ms, ce qui peut prêter à confusion.

note: dans le cas d'un Ethernet SmoothStepper (ESS) quelque soit le réglage dans la config, la tempo de broche est toujours à exprimer en secondes ; j'ignore ce qu'il en est avec une NVEM ; à vérifier.

La doc mach3 parle de synchronisation des axes (pour faire du suivi d’arête par exemple)

Tu peux préciser ou exactement dans la doc ? ; je n'ai jamais vu cette possibilité ; je sais que LinuxCNc peut le faire, mais sur Mach3 je n'en ai jamais entendu parler.

Il est possible de mettre des équations d'axes, afin de lier le mouvement d'un axe à un autre, mais je suppose que ce ne n'est pas la même chose.
https://www.usinages.com/threads/correction-dangles-sous-mach3.78036/



++
David

Bonjour
Merci David pour les explications.
J'ai trouvé les mentions de "co-ordinated linear motion " dans le manuel Mach3Mill_1.84.pdf chap 10.1.5. C'est fait apparement par du code interne a Mach3 via les commandes G0 G1 etc..

J'ai besoin de comprendre un peu mieux la synchro entre le Gcode et les macros, donc je reformule
Si j'ai par exemple un code qui fait de la digitalisation de Z
G1 x1 y2 z3
G31 z-5
M500 'delai
G0 x0 y0 z0
G31 et M500 s'executeront simultanement et si je met la boucle 'while ismoving' dans M500 alors G0 ne sera executee que quand G31 z-5 sera terminée ?

Le deuxieme probleme que j'ai avec G31 c'est que ne sont stockees dans le fichier d'enregistrement que les valeurs du G1, le G31 n'ecrit pas la valeur du Z qu'il a detecté alors qu'il est censé ecrire la derniere valeur. Je suis parti sur l'hypothese que c'est aussi un probleme de delai.

A+
Jacques

G31 et M500 s'executeront simultanement et si je met la boucle 'while ismoving' dans M500 alors G0 ne sera executee que quand G31 z-5 sera terminée ?

normalement le G0 ne s'effectuera qu'après que le G31 soit terminé, tant que ce sont des codes G, il sont exécutés séquentiellement ; par contre le M500 sera exécuté en même temps que le G31 faux ; je viens d'essayer avec

G31 Z-2
M3
G0 X0 Y0
M30

tant que le G31 n'est pas fini, le M3 n'est pas exécuté ; donc:

Si on a une ligne avec un M suivie d'une ligne G, le M et le G qui le suit s'exécutent en même temps (pour une macro en VB ; il y a quelques code M qui ne sont pas des macro VB)

Si on a une ligne avec un G suivie d'une ligne M, le M ne s’exécutera que quand le G sera fini.

par exemple dans le GCode produit par le wizard digitize, il n'y a aucune pause et ça fonctionne parfaitement

(Digitize File)
M40 'créer fichier de numérisation et écrire les coordonnés pour chaque G31
G92X0Y0Z0
F100
G0X0Y0Z5
G31 Z-6.2774385622042e+066
G0 Z5
G0X0.25Y0Z5
G31 Z-6.2774385622042e+066
G0 Z5
G0X0.5Y0Z5
G31 Z-6.2774385622042e+066
G0 Z5
G0X0.75Y0Z5
G31 Z-6.2774385622042e+066
G0 Z5
G0X1Y0Z5
G31 Z-6.2774385622042e+066
G0 Z5
....
...
M30 'fin du programme et fermeture du fichier de numérisation

par contre si on génére du GCode via une macro en VB, alors il faut mettre des pause entre les instructions GCode comme le G31 et le mouvement suivant.

exemple de la version de palpage en VB (les instructions GCode sont générée avec la fonction Code() )

...
...
Code "G31 Z"&ZNew 'lancer le palpage

While IsMoving() 'attendre une détection
Wend

ZNew= GetVar(2002) 'lire la valeur du point de contact

Code "G0 Z"&ZNew 'remonter si dépassement

While IsMoving() ' attendre fin du mouvement
Wend

...
...

Le deuxieme probleme que j'ai avec G31 c'est que ne sont stockees dans le fichier d'enregistrement que les valeurs du G1, le G31 n'ecrit pas la valeur du Z qu'il a detecté alors qu'il est censé ecrire la derniere valeur. Je suis parti sur l'hypothese que c'est aussi un probleme de delai.

je ne sais pas trop ; pour ma part je l'ai déjà utilisé et ça fonctionnait bien, j'obtiens bien les 3 coordonnées dans le fichier de digit.

http://www.metabricoleur.com/t2083-numerisation-3d-avec-mach3#28389

++
David

J'ai trouvé les mentions de "co-ordinated linear motion " dans le manuel Mach3Mill_1.84.pdf chap 10.1.5. C'est fait apparement par du code interne a Mach3 via les commandes G0 G1 etc..

Ok, rien à voir avec ce que j’imaginais ; ici ils expliquent simplement que pour suivre un parcours à une vitesse d'avance donnée, et comme il faut faire bouger plusieurs axes à la fois pour suivre la trajectoire, la vitesse de chaque axe variera constamment en fonction de l'angle de la trajectoire de façon à ce que la vitesse linéaire résultante sur la trajectoire soit conservée (si c'est effectivement possible) ; c'est le fonctionnement de base de tout système de pilotage.

++
David

Re bonjour

Dans mon cas si j'utilise le code généré par "digitize wizard" tel quel, le G0X1Y0Z5 de ton exemple est exécute avant que le G0 Z5 soit terminé ce qui m'a cause des collisions avec la probe d'ou l'insertion d'un délai. J'ai peut être un pbm de config mais quoi ?

J'ai effectivement 3 coordonnées écrites dans le fichier mais ce ne sont pas les bonnes en tout cas pour le Z.
dans l'exemple:
G0X0Y0Z5
G31 Z-6.2774385622042e+066

je retrouve dans le fichier: 0,0,5 et pas la valeur réelle de Z lors de la detection de la probe.

Mystere
A+
jacques

C'est bien possible que ce soit dut à la NVEM, car c'est justement un problème connu sur la plupart des cartes d'interpolation chinoises (et sur la NVEM), elles ne mettent pas à jour les variables interne de Mach3 qui sont censées contenir les positions XYZ au moment du contact (var 2000 à 2002 pour XY et Z) ; c'est ce qui fait que sur les macros de palpage de longueur d'outil, il faut les modifier en allant chercher la valeur dans la visu au lieu de la valeur de la variable. A tout les coups, la fonction OpenDigFile()  (M40) utilise la valeur des variables, et comme elle ne sont pas gérées par la NVEM, ça te fait un fichier qui contient n'importe quoi.

++
David

G0X1Y0Z5 de ton exemple est exécute avant que le G0 Z5 soit terminé ce qui m'a cause des collisions avec la probe d'ou l'insertion d'un délai. J'ai peut être un pbm de config mais quoi ?

Ça pourrait être dut au mode vitesse constante s'il est activé ; essai de mettre un G61 en début de ton GCode (trajectoire exacte). ça pose problème surtout si la vitesse demandée est importante par rapport à l'accélération, plus l'accélération est faible par rapport à la vitesse et plus ça arrondis les trajectoires lors d'un changement important de direction que ce soit en XY en XZ ou en YZ ...

http://www.metabricoleur.com/t7112p75-premiere-utilisation-de-cambam#149251

re ; après vérification, le mode vitesse constante n'est pas actif entre deux G0 donc si c'est le cas pour toi, c'est peut être bien une bizarrerie de cette carte ...

un exemple en vidéo ; en premier avec des G1 en mode vitesse constante, on voit bien que le X commence à bouger avant que le Z ne soit arrivé à +5, par contre dans la 2ieme partie avec des G0 à la place des G1, le X ne bouge pas tant que le Z n'est pas arrivé en haut.



par contre ; d'un G0 à un G1 il n'y a pas de lissage le G1 ne commence pas tant que le G0 n'est pas fini, mais d'un G1 à un G0 il y a lissage de trajectoire si la vitesse constante est activée
++
David

merci David pour ton support.

Pour le probleme des valeurs enregistrees, je crois que je vais devoir me taper un peu de VB script dans la macro pour utiliser les valeurs de la visu. Chose interessante, lorsque je monitore les valeurs des variables avec la visu operateur (GCode Var monitor), la valeur de Z est bien erronée.

Donc j'essaie ca.
Pour le probleme des axes, comme le delai resoud le probleme, je vais conserver ca avant de jeter cette carte

A+
Jacques

je crois que je vais devoir me taper un peu de VB script dans la macro pour utiliser les valeurs de la visu

Oui, c'est à tenter ; je suppose que la fonction OpenDigFile() n'écrit une valeur que quand les var 2000...2002 changent ; peut être qu'en changeant leur valeur via un script en y copiant les valeurs XYZ des visu ça marcherait ...

++
David

re

en regardant la doc de programmation, je viens de voir que c'est le G31 lui même qui déclenche l'écriture dans le fichier ouvert par OpenDigFile(), donc si tu modifie la variable après ce sera trop tard ... . Il faudra gérer toi même une ouverture et écriture de données dans un fichier en VB, sans passer par le OpenDigFile() de Mach3 mais avec les instructions de gestion de fichier standards du Visual Basic.

Sub OpenDigFile()
This function opens a digitization log file. When OpenDigFile is executed a FileOpen
dialog will be displayed, and the user can select an existing file, or enter a new file name,
to which digitization (probing) data points will be written. Once opened, G31 commands
will cause the probe trigger position to be written to the digitization file. When
digitization is complete, CloseDigFile() can be used to close the file.


++
David

Re
Je crois que OpenDigfile ne fait qu'ouvrir le fichier. Je pense que c'est le G31 qui enregistre les valeurs. Je vais chercher comment obtenir les valeurs des visus, probalement avec les OEM values ...
oops on est en train de taper en meme temps
+
jacqueq

oui, GetOEMDRO (page 24)

dro n° 800, 801 et 802 pour XY et Z

https://www.machsupport.com/wp-content/uploads/2013/02/Mach3_V3.x_Macro_Prog_Ref.pdf

++
David

Merci pour les infos. Ca m'a évité de chercher
Ca a l'air de marcher sur le PC de bureau. Demain j'essaie sur la machine.
Bonne soirée
A+
Jacques

Bonjour
Bonne nouvelle. J'arrive enfin a avoir un fichier de points digitalizés.

Je resume les modifications que j'ai faites:
- Avec Machscreen modifier le wizard de Art Fenerty pour qu'il insere des commandes M500 et M501 (scripts crées pour l'occasion) dans le code généré
- Créer le script M500 qui introduit une boucle while Is moving, sleep(100), wend et ouvre/crée un fichier en mode append pour le stockage des données enregistrées, lire les valeurs des visus (x,y,z,a) et les écrires dans le fichier, fermer le fichier.
- Créer le script M501 qui introduit juste un délai
- Créer un script M40 qui décrit l'emplacement du fichier digitalisation et les actions a prendre.

J'ai également ramené la valeur du look ahead dans l’écran de config general à 1. J'ai eu des comportements bizarres avec G31 (ex z continue a descendre bien que la probe soit détectées jusqu’à sa valeur max).

ca a l'AIR de marcher, on verra avec des digitalisations de pieces plus importantes si MACH3 ou NVEM se plantent (bloqués).

Merci encore David pour les conseils et les infos. Les scripts sont dispo en mp pour ceux que ca intéresse.
A+
Jacques

Salut,

J'ai également ramené la valeur du look ahead dans l’écran de config general à 1. J'ai eu des comportements bizarres avec G31 (ex z continue a descendre bien que la probe soit détectées jusqu’à sa valeur max).

Le look ahead est utilisé par le planificateur de trajectoire en mode vitesse constante ; c'est le nombre de lignes de Gcode (des mouvements) que Mach3 va lire à l'avance pour calculer une nouvelle trajectoire qui permettra d'essayer de conserver une vitesse d'usinage constante ; ça implique de recréer une nouvelle trajectoire qui collera au plus près de la trajectoire réelle mais qui "arrondira" les changements de directions pour conserver autant que possible la vitesse d'usinage demandée même dans les angles. Par exemple un look ahead de 20, créera une nouvelle trajectoire "lissée" à partir d'une série de 20 lignes.

Concernant le G31 qui ne s'arrête pas même lorsqu'il est arrivé à la valeur maxi donnée, je l'ai remarqué aussi, et apparemment ça vient aussi de la carte/plugin.

Sur le PC avec un Windows 32bits de la maison et un port // (mais non reliée à une machine), le G31 fonctionne parfaitement (avec une simulation du contact par une touche)

Sur le PC avec un Windows 64bits de la maison (un autre) et qui n'a pas de port // (et donc pas non plus le pilote spécifique de port // de Mach3) ni de carte d'interpolation externe, le G31 ne fonctionne pas du tout ; si je simule un contact, la LED probe s'allume bien, mais l'axe ne s'arrête pas, que ce soit sur contact ou lorsqu'il atteint la valeur maxi. C'est le même problème avec une simulation des contacts de référencement, les LED s'allument, mais les axes ne s'arrêtent pas. Apparemment c'est donc la carte d'interpolation (ou son équivalent logiciel = le "pilote" du port // ) qui doit renvoyer les infos à Mach3 ....

Sur le PC avec la carte d'interpolation en Ethernet (ESS de warp9) ça fonctionne parfaitement.

Il semble donc que tu ai trouvé encore un nouveau bug sur cette NVEM ...

C'est un peu (beaucoup) ce qui m'avait incité à me ruiner avec un ESS lorsque j'ai décidé de me passer du port //, il semble que la plupart des cartes Chinoises, même chères comme les XHC, aient des bugs avec certaines fonctions de Mach3, voir, ne les gèrent pas du tout. C'est souvent des fonctions "annexes", voir "exotiques" comme la gestion de la THc (découpeur plasma), le référencement double axe, le palpage en XY, la mise à jour des variables internes, le ralentissement des axes avant butée .... etc.

Normalement, d'après la doc de Mach3, il n'y a que 2 fonctions qui ne peuvent pas fonctionner avec une carte externe et qui ne fonctionnent qu'en port // ; SetTimer() et GetTimer(), mais tout le reste devrait théoriquement fonctionner ... si la carte le gère ... et si le plugin transmet bien les infos.

++
David

Bonjour

La nuit portant conseil, j'ai pensé que ca pouvait être une problème de contrôle de flux (com) entre la boite, le driver et le soft Mach3. En effet 95% des G31 se passent bien => la carte détecte le contact, le driver transmet et M3 enregistre. Pourquoi parfois ca n'est pas pris en compte ? Je pars de l'hypothese que les trois entités fonctionnent vu que ca marche en general. Donc ca veut dire perte de l'info entre :
La carte et le driver => LAN
Le switch et la carte => parasitage. Je n'y crois que tres peu car le switch est un swicth transistorisé donc pas de rebond, signal bien propre.
Le driver et Mach3 => ??

Le LAN c'est bien possible de par sa techno ou sa config. En cas de perte de packet c'est retransmis mais vu comme c'est branché (cable standard sur du point a point). Il y a des tas de choses configurables sur la carte LAN et NVEM ne parle que de l'adresse IP. Autre chose que j'ai remarqué c'est que la LED orange sur la carte NVEM est toujours allumé, ca m'a etonné mais vu que ca communique je ne suis pas posé plus de questions.

Je vais creuser un peu plus sur ca.
A+
jacques

Salut,

Il me semble me souvenir que quelqu'un sur CNc zone ou le forum Mach3 avait des problèmes de réactivité et qu'il les avait solutionnés en jouant avec les valeurs du "nettoyeur" de rebond de contact. ("Debounce Interval" dans general config) mais je ne me souviens pas si ça avait un rapport avec une NVEM ou le G31.

avec un switch transistorisé, je suppose que tu peux mettre Debounce Interval à 0.

note: même avec une carte d'interpolation, il vaut mieux ne pas toucher au PC quand ça numérise/usine (ne pas changer d'écran ou jouer avec l'afficheur de parcours 3D)

++
David

Re

Tu a des réglages dans le plugin de la NVEM ?

++
David

Re

Pas de réglage dans le plug in. La config du Plugin donne juste la version du plugin, du firmware et le nombre d axes disponibles. ca donne également la possibilité de lire/(enregistrer un nouveau firmware). donc rien de réglable.

Voila les manips que j'ai fait sans changement notoire du comportement:
Debounce interval mis a zero (etait à 2000)
Config du driver de la carte LAN:
Controle de flux: Rx et Tx active

J'ai observé que lors de la descente jusqu'au -z max dans l'ecran diagnostic de M3, la led digitize etait on mais ca continue quand meme. Que mach3 (Version R3.043.066) se plante (programme en run mais plus rien ne se passe, stop pgm mais toujours pas acces aux axes) de temps en temps dans le programme. Un reset et j'ai de nouveau acces aux axes via le mpg. Bref je commence a désespérer à avoir un truc stable.

Jacques

Salut,

Que mach3 (Version R3.043.066) se plante

Ah oui ! , la 066 est à éviter comme la peste, elle fait des bizarreries avec les scripts, le référencement, etc ... ; la dernière version stable de Mach3, c'est la 3.042.062

tu trouvera la 062 ici
https://warp9td.com/index.php/sw/software-mach

++
David

Bonjour

Peu ou pas de progrés mais des infos interessantes.
1) Revenu a la version R3.043.0062. Je n'ai pas desinstallé, juste re-installé par dessus. Le n° de version affiché par M3 est bien 0.62. Pas de changement de comportement, z descend jusqu'a la limite programmée de temps en temps (2 ou 3 fois) pendant tout le programme (156 lignes). M3 se plante arrivé à 80% env de l'execution, parfois ca se termine correctement.
2) Fait tourné M3 avec privileges admin => memes resultats
3) Fait tourné M3 avec comptibilité XP SP2 => memes resultats
4) Viré l' antivirus et le firewall => memes résultats

Enregistrement du fichier de digitalisation:
Contrairemant a ce que j'ai dit predemment, la valeur Z n'est pas enregistrée non plus (reste a zero) alors que X et Y sont OK pourtant lorsque je fait tourner le script a la main (vb script editor du menu operator) les valeurs XYZA de la visu sont bien enregistrées. mystere.
La possibilité de faire de la digitalisation s'éloigne

Carte LAN:
J'ai reconfiguré le driver de la carte LAN du PC (NVIDIA) pour être le plus simple possible. J'ai descendu la vitesse de transfert a 10Mbps (etait à 100mbps) et mis en full duplex (half duplex ne change rien)=> la led orange de la carte NVEM s'est eteinte mais pas de changement de comportement.

J'en ai assez pour cette semaine.

Je suis donc preneur sur des infos sur les cartes motions controller Ethernet. Tu as je crois Warp9 ESS, j'ai vu egalement AXBB-E de CNCdrive compatible mach3-4 et UCCNC ou CSMIO/IP-M
Autre question a ce niveau ne vaut il pas mieux passer sous M4? ou UCCNC ?
J'aimerais quand meme que ces nouvelle cartes me permettent au moins 4 axes et digitaliser...et si possible reutiliser mes alims et drivers moteurs

Merci pour ton support et ton aide ca me remonte le moral
A+
jacques

Salut,

Alors l'AXBBE, c'est fait par CNc drive, le même fabricant que l'UC100, qui semble avoir une bonne compatibilité avec Mach3 ; ces 2 cartes fonctionnent aussi sous UCCNC.

Pour le choix entre UCCNC et Mach3, je dirais que UCCNC est moins cher et est assez semblable à Mach3 et toujours mis à jours, mais il n'y a pas, je pense, toutes les possibilités de manipuler les écrans ni d'écrire des fonctions complexes en VB Edit: Si, il y a aussi !.  Pour Mach4, le peu que j'ai vue ..... c'est que tout à changé du pt de vue programmation, pas le même langage de script, les mêmes macros etc ... et peu d'aide pour l'instant ; même si les 1ière versions sont sorties en 2014/15 il manque encore du "background" si on veut utiliser des trucs un peu complexes ; par exemple il y a quelque temps un gars à demandé des infos pour faire un script sous Mach4 sur usinage ... et personne n'a répondu ... pas encore assez connu.

CSMIO, ça à l'air très bien, mais pas donné !!

J'aimerais quand meme que ces nouvelle cartes me permettent au moins 4 axes et digitaliser...et si possible reutiliser mes alims et drivers moteurs

Elles en sont toutes capable ; l'AXBBE intègre la BoB en plus de la carte d'interpolation (et je pense que c'est pareil sur la CSMIO, mais je ne connais pas trop le produit) par contre il semble que l'AXBBE n'ai pas de convertisseur PWM 0-10V pour la broche edit: si il y est , donc il faut certainement un convertisseur externe, ou piloter la broche en RS485. L'ESS n'a pas de BoB intégrée, donc tu met une BoB en port // de ton choix dessus (qui peut contenir un convertisseur PWM, des relais ..) on peut brancher 3 BoB sur l'ESS (soit 3x 17 E/S). L'ESS nécessite une petite alim 5V 2A pour son alimentation, et la BoB ... et bien ça dépend du modèle ; la mienne accepte une tension d'alim entre 15 et 75V donc je peux utiliser la même alim 48V que mes drivers par contre si tu a des switch inductifs, la BoB doit être alimentée avec une tension compatible avec les switch (dans mon cas, c'est des mécaniques, donc la même alim 48V fait pour tout ; BoB et drivers)

++
David

Bonjour

Je pense que je suis mur pour le remplacement de la NVEM. En short list j'ai retenu AXBBE et ta config Warp9 ESS. Ta config permet d'avoir plus de possibiltées (6 axes etc ..) par contre il faut l'integrer dans un boitier. Si j'ai bien compris il faut pour realiser un controller fini:
1 boitier
1 alim 5V
1 ESS
1 ou plusieurs Breakout boards
des cables de connections sur l'ESS
des connecteurs male femelle port parallele

Bref si tu as une liste du matos, je suis preneur ca m'evitera d'en oublier.
Chez qui as tu acheté ta config ? Rien trouvé en France

Merci de ton aide
Jacques