La librairie keyboard émule des appuis clavier d’un clavier Qwerty.
Tu pourrais modifier G90 par Gçà dans le code mais c’est illisible ou alors modifier les valeurs des touches dans Keyboard.cpp.
C’est ce qui est fait ici:
https://github.com/martin-leo/KeyboardAzertyFr/tree/master/src
Tu peux télécharger et utiliser cette librairie modifiée
Super merci. J essaye et je te dis quoi comme disent nos Chtis.
Télécharger Outlook pour Android
Bon je seche un peu (voire beaucoup)
j'ai fait 3 tentatives infructueuses:
1 ) j'ai remplacé C:\Program Files (x86)\Arduino\libraries\Keyboard\src\ Keyboard.cpp et Keyboard.h par KeyboardAzertyFr.cpp et KeyboardAzertyFr.h. en gardant les noms originaux "keyboard" Ca n'a rien changé, je pense que ca ne recompile pas la librairie et que ce sont les anciens compilés qui sont toujours utilisés.
- j’ai créé une librairie KeyboardAzertyFr dans C:\Users\Pierre\Documents\Arduino\libraries\KeyboardAzertyFr\src en remplacant dans le c arduino tous les appelles Keyboard par KeyboardAzertyFr . La c’est le fichier c arduino qui ne compile pas car il ne trouve pas la librairie HID.h dans KeyboardAzertyFr.h alors qu’il la trouve dans la librairie originale keyboard.h
3 ) j’ai remplacé dans la librairie originale Keyboard.cpp et Keyboard.h toutes les definitions de touches que j’ai trouvées dans KeyboardAzertyFr. J’ai détruit les directory de build et de cache (C:\Users\Pierre\AppData\Local\Temp\arduino_build_72482) pour l’obliger (je croyais) à tout recompiler. Le resultat est un retour au debut, c’est à dire qu’il ne recompile pas le nouveau Keyboard.cpp et Keyboard.h et je me retrouve avec un clavier americain comme au debut.
En fait dans les tentatives 1 et 3, je n’arrive pas a lui faire prendre en compte les modifs que j’ai faites dans le code Keyboard.cpp et Keyboard.h, il reste sur les versions originales quoi que je fasse.
une idée?
tes tentatives 1 et 3 devraient fonctionner mais on dirait que ce n’est pas le fichier que tu crois qui est compilé.
Chez moi sous linux ça marche.
Ce que tu peux faire, c’est activer dans les préférences les détails de compilation, il y a une croix à cocher.
Ensuite tu compiles et tu regardes ce qui est affiché.
A un moment il doit y avoir le chemin complet du fichier Keyboard.cpp
Sur mon PC c’est:
home/eti/arduino/arduino-1.8.8-linux64/arduino-1.8.8/libraries/Keyboard/src/Keyboard.cpp
Si tu remplaces ou modifies ce fichier ça devrait marcher.
merci Etienne
effectivement, comme j’utilise un teensy, il semble utiliser un keyboard different : (x86)\Arduino\hardware\teensy\avr\cores\teensy3" “C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\usb_keyboard.c” -o “C:\Users\Pierre\AppData\Local\Temp\arduino_build_415878\core\usb_keyboard.c.o”
dans ce repertoire je trouve bien un
usb_keyboard.c
qui fait appel a un
#include “keylayouts.h”
dans le #include “keylayouts.h” il y a
//#define LAYOUT_US_ENGLISH
//#define LAYOUT_CANADIAN_FRENCH
//#define LAYOUT_CANADIAN_MULTILINGUAL
//#define LAYOUT_DANISH
//#define LAYOUT_FINNISH
#define LAYOUT_FRENCH
//#define LAYOUT_FRENCH_BELGIAN
//#define LAYOUT_FRENCH_SWISS
//#define LAYOUT_GERMAN
//#define LAYOUT_GERMAN_MAC
//#define LAYOUT_GERMAN_SWISS
//#define LAYOUT_ICELANDIC
mais le fait de decommenter #define LAYOUT_FRENCH ne change rien.
arf le teensy fait plein de trucs bizarres…
J’ai vu que dans le menu “tools” il y a “keyboard layout” dans l’IDE arduino quand tu sélectionnes teensy.
Il faut peut-être tout simplement choisir “French”
oh punaise, j’ai honte.
Ça fait depuis hier que j’ai le pif dans le C sans grand succès. Et tu as raison il y a un menu dans l’IDE arduino pour choisir le clavier. C’est dur l’aprentissage :).
Ca Maaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarche …
Merci, tu es mon héro
Cool!
Faut dire aussi que le #include <Keyboard.h> peut induire en erreur.
Tu peux essayer de le virer pour voir si ça marche encore ?
exact, meme en virant le #include <Keyboard.h> ca ne change rien 
Suite avec une petite discutions avec thomas jeudi j ai quelque bobine avec des tores que l on pourrais utiliser pour éliminer les parasites
J’ai un lot de ferrite qui ne me sert pas. Elle se clipse sur câble. Dès que je peu je les apporte.
Le sam. 27 avr. 2019 à 20:07, gaeldu63 via Discourse ACoLab noreply-forum@acolab.fr a écrit :
Bonjour à toutes et tous.
Grande nouvelle
Hier soir, avec Thomas nous avons fait un grand pas en avant. La CNC a fait un programme d’usinage (sans fraise of course) complet pilotage de la broche et déplacements sur les 3 axes. Cela a été fait avec un autre contrôleur que celui de l’ACoLab. Il reste encore un problème étrange de potentiel assez énorme dans le blindage de la broche a régler mais la faisabilité avec les options choisies (GRBL + Bcnc) est prouvée. Ce problème de potentiel dans le blindage alors qu’il n’est relié à rien est la source d’une grosse partie de nos chagrins de ces 2 derniers mois.
Un démontage de la broche, si cela est possible pourrait peut-être nous éclairer ?
Mais auparavant, pour ce genre de phénomène, un premier test est souvent parlant : charger ce potentiel avec une résistance et mesurer si un courant “significatif” passe entre cette “pseudo-masse” et la terre “bâti” ou autre référence . C’est rapide et sans risque.
Bravo les gars ! Désolé de vous avos laissé tombé ce derniers jours mais j’ai quelques obligations à la maison ces jours ci !
Le jeu. 16 mai 2019 à 11:11, Pierre via Discourse ACoLab noreply-forum@acolab.fr a écrit :
Saga la grande CNC : Ce n’est qu’un début, continuons le combat…
Au cas où il y aurait un regulectif ce soir, je ne suis pas sûr de pouvoir y assister donc je vous fais un point de la grande CNC.
Ou nous en sommes :
Définition :
-
filtre niveau 1 = résistance + condensateur de l’explication https://github.com/gnea/grbl/wiki/Wiring-Limit-Switches
-
Filtre niveau 2 = solution avec opto de l’explication https://github.com/gnea/grbl/wiki/Wiring-Limit-Switches
La semaine dernière la machine fonctionnait sans l’arrêt d’urgence. Fonctionnait veut dire : Faire un programme complet (12 minutes environ de perçages, contournages avec arrêt et démarrage de broche entre chaque phase). Il me semble me rappeler cependant que dans cette situation j’ai eu un plantage en fin d’usinage une fois. Plantage veut dire être obligé de rebooter le Pc pour reprendre la main).
Dès que je branchais l’arrêt d’urgence, au démarrage de broche, la broche faisait quelques tours et s’arrêtait systématiquement. Le PC n’était pas plante, je pouvais sortir de Bcnc et relancer avec le même résultat.
Hier soir. J’ai mis un filtre provisoire (niveau 1) sur l’arrêt d’urgence : J’ai pu faire un usinage complet avec l’arrêt d’urgence branché normalement. Le seul problème a été 2 pauses non déclenchées volontairement durant l’usinage. Ces pauses ont été réglées par un « start » et l’usinage a repris ou il s’était arrêté.
Conclusion hâtive : Le filtre marche sur l’arrêt d’urgence, il faut donc en mettre sur toutes les commandes externes (arrêt d’urgence, palpeur, pause, start, reset). Donc acte. Remarque : je n’ai pas mis de filtre niveau 1 sur les fins de courses.
Résultat du test après avoir mis un filtre niveau 1 sur les 5 fonctions externes sauf fins de courses :
Je n’ai plus le problème sur l’arrêt d’urgence la broche démarre bien un certain nombre de fois mais l’usinage fini toujours par planter le pc aléatoirement avec reboot obligatoire.
Partant de là, je vois 3 stratégies :
- Abandonner. Cette première stratégie n’a pas ma faveur.
- Retourner vers Linuxcnc. Pourquoi pas, je ne connais rien à Linuxcnc donc ça m’intéresse mais je ne partirai qu’avec au minimum une personne connaissant linuxcnc.
- Epuiser les dernières cartouches Bcnc + Grbl.
Il me semble que nous avons 2 problèmes.
a) Des impulsions sur les lignes externes ne conduisant pas à un plantage du Pc mais simplement a une action sur la ligne en question (pause, ou arrêt d’urgence ou …). Sur ce problèmes les filtres niveau 1 sur les lignes externes semblent améliorer la situation (à confirmer).
b) Un plantage aléatoire du port USB qui conduit à un reboot du Pc et là-dessus je ne suis pas certain que le filtre soit la solution.
Pour continuer sur dans cette voix je ne vois que la manière suivante.
- Débrancher les lignes externes (arrêt d’urgence, palpeur, pause, start, reset) jusqu’à trouver un fonctionnement stable de la machine. Stable veut dire (disons 4 usinages de 12 minutes sans le moindre problème).
a. Si on arrive à une situation stable on passe à 2
b. Si on n’arrive pas à une situation stable on débranche les fins de course
i. Si on arrive à une situation stable on passe à 2
ii. Si on n’arrive pas à une situation stable il faut abandonner la solution GRBL + Bcnc et revoir ce qu’on peut faire avec linuxcnc( à moins que vous ayez d’aurtres idées). - Si on est arrivé à une situation stable, on doit pouvoir dire que le problème est bien sur les lignes externes (soit les 5 fonctions, soit les 5 fonctions + les fins de courses suivant le résultat trouvé en 1).
a. On commence par virer les 3 fonctions dont on peut se passer (pause, start, reset).
b. On met un filtre niveau 2 sur les fonctions externes incriminées.
i. Ça marche on organise un apéro
ii. Ça ne marche pas on abandonne définitivement GRBL et Bcnc et on passe à autre chose.
Je souhaite votre avis sur les 3 alternatives et eventuellement si vous avez d’autres idées.
Pierre
J’ai juste une question, Pierre : Sommes-nous partout en NC sur les infos carte ?
Ça, c’est déjà un premier point pour éviter les effets d’antenne des fils “en l’air”
Concernant le lien vers le site et les remarques qu’on y trouve sur les filtres et leur efficacités.
Mon avis : les opto-coupleurs sont effectivement des excellents filtres. En pratiquant le NC+filtre RC+opto-coupleur, on devrait obtenir une bonne protection.
Sur les filtres RC, il faut aussi voir la bande passante par rapport aux limites de détection de notre interface.
Je me souviens qu’en industrie, on avait 2 types de filtres RC suivant la vitesse d’acquisition, la fréquence du signal et vitesse de traitement du process (cycle régulier d’acquisition des entrées ou gestion par interruption.
J’avais un copain qui était spécialiste de la chasse à l’artefact et qui passait son temps à faire ça sur nos équipements.
Si, malgré cela on avait encore des aléas de fonctionnement, il serait intéressant de regarder de plus prêt le signal sur l’entrée de la carte avec un analyseur d’état logique.
C’est long, mais le résultat est souvent de bon enseignement.
Merci pour cette réponse François
L’arrêt d’urgence (idem pour pause, reset, start) est typiquement dans ce que tu dis c’est-à-dire NO avec un fil en l’air. La PIN est à + 5V en pull-UP et est mise à la masse lors de l’activation de l’urgence, ou pause ou autre. Il n’y a pas de paramètre dans GRBL pour inverser la logique. Pour le palpeur et les fin de courses, on peut faire ce que l’on veut (car prévu dans les paramètres de GRBL) et le palpeur que j’ai fabriqué est un NC.
Pour les filtres, je suis super intéressé par ce que tu dis, mais mes faibles connaissances en la matière ne me permettent pas d’appliquer. Dois-je comprendre que ta préconisation est de mettre des opto sur les fonctions externes (ca je peux faire) et que si ca continue à merder, tu m’aideras sur l’analyse + poussée ?
Pierre
Il est facile de transformer un no en nf avec juste un transistor et quelque résistance cela permettrais d enlever l effet rtl2 comme je l appel
On fait ça la prochaine fois ?
Il y a tout ce qu’il faut à l’Acolab pour réaliser ces petites interfaces “inverseur de signal”
@gaeldu63 : tu peux nous faire un brin de schéma ?
Pour ma part, je ne pourrai venir que le 29/6 au plus tôt.
Pour les filtres, je pourrais regarder ça sur des cartes d’entrées automates industriels que j’ai sur une étagère. J’apporterai ça pour “analyse”.