Je voudrais avoir un bouton poussoir physique pour lancer le programme. Ca remplacerait l'utilisation de la touche R du clavier. J'avais commencé à coder un truc sur une attiny85 (genre arduino) pour avoir juste une touche R déportée câblée sur USB.
Et puis en cherchant un peu je suis tombé sur ça :
Bonsoir,
Tu es dans la bonne voie,
Ce sont des instructions à rentrer avec un éditeur dans les 2 fichiers .ini et .hal
une instruction dans .ini dans la section:
[HAL]
HALUI = halui
et les autres dans le fichier .hal
Attention, il ne faudra plus utiliser stepconf après !
tu remplaces cette instruction générique <your input pin> par une instruction
analogue à celle ci : parport.0.pin.13.in 13 étant un exemple de pin d'entrée de libre sur ton port //
Ensuite il faut que tu rentres un composant hal pour la fonction logique ET
sinon un vieux joystick usb et tu as 10 as 14 entrée ttl assignable tu garde le pcb et tu soude les inter que tu as besoin , ça se trouve a 1€ dans les cash et en brocante
J'ai rajouté les lignes au fichier *.hal, et ça fonctionne, sauf que ça a la fâcheuse tendance à démarrer tout seul lorsqu'on ouvre un nouveau programme ...
Donc un peu embêtant, si on fait pas gaffe ça peut faire de la casse ...
Ah oui j'ai écrit : parport.0.pin-11-in , c'était cette synthaxe partout ailleurs, mais je pense pas que ça puisse changer le comportement prévu ...
Bonne année à toi aussi.
Il faut que tu ailles scruter le signal avec halscope pour voir un peu avec quelle action le parasite est corrélé.
De toute façon, comme c'est un interrupteur physique, tu as tout intérêt à un intercaler un anti-rebond logiciel
qui va en même temps, en principe, éliminer une impulsions parasite brève.
C'est le composant hal debounce qu'il faut intercaler entre le signal du port // et la commande halui
j'ai plus l'impression que c'est une question de "valeurs initiales", ou de logique : du type : dès que toutes les conditions au démarrage sont remplies ça démarre ...
C'est peut-être pas un "and" qu'il faut ... ?
Car c'est vraiment : je fais "file open ...", dès que le fichier est chargé ça part ...
L'entrée halui.program.run est activée par le bouton externe ou par le bouton axis et si le mode auto est validé.
Je pense qu'il faudrait déjà voir si c'est une activation fugitive et reproductible avec halscope,
ou si cela a une allure de parasite.
Merci pour les pistes !
Je vais essayer de voir avec Halscope ce soir (jamais encore utilisé - ça sera une découverte).
Pour la reproductibilité, en fait c'est systématique ... suffit d'ouvrir ou de réouvrir un fichier (avec du gcode) et le programme démarre (si les axes sont "enabled" et "zeroed") ...
Mais par le bouton ça marche aussi ...
Quand je branche directement la sortie halui.mode.is-auto sur l'entrée halui.program.run
il se produite le phénomène que tu décris.
Normalement ça n'est pas possible car le signal, pour passer, doit satisfaire la condition ET avec l'activation
du bouton.
Donc pendant un bref moment, soit la condition ET n'est pas pris en compte, soit une pulse parasite se
promène sur la voie bouton ? si c'est transitoire dans les 2 cas,
faire passer and2.0.out à travers un timedelay ou un debounce devrait résoudre le soucis.
Concernant la tempo du debounce comme c'est un compteur décompteur la valeur du paramètre
doit correspondre à n fois une boucle basethread.
J'ai réussi à faire fonctionner correctement le bouton :
pour cela j'ai splitté la première ligne de l'instruction (voir http://linuxcnc.org/docs/html/hal/halui-examples.html) en deux, comme d'ailleurs suggéré dans le même lien.
La partie USB m’intéresse aussi, mais ça sera pour un peu plus tard...
Faut-il aussi le mapper dans HAL, ou c'est comme un deuxième clavier ?
J'ai réussi à faire fonctionner correctement le bouton :
pour cela j'ai splitté la première ligne de l'instruction (voir http://linuxcnc.org/docs/html/hal/halui-examples.html) en deux, comme d'ailleurs suggéré dans le même lien.
La partie USB m’intéresse aussi, mais ça sera pour un peu plus tard...
Faut-il aussi le mapper dans HAL, ou c'est comme un deuxième clavier ?
On peut rédiger les branchements net sous la forme d'une liaison par ligne pour la clarté de compréhension.
Les flèches sont facultatives, mais si on les utilise, leurs sens est important depuis la version 2.7
Le fait de scinder une ligne ne devrait pas résoudre le problème.
Il s'est peut être passé autre chose au moment de l'édition de la modif.
J'ai testé les premières jeux d'instructions (ligne non scindée), je n'ai pas ce soucis ?
Mais je rentre sur une entrée/sortie mesa, pas sur un port//.
Euh, j'ai une version assez ancienne : 2.5 je crois.
Je suis sur port parallèle, mais à travers une breakoutboard
La seule chose que j'ai changé au fichier c'est de splitter la ligne en deux,
puis j'ai aussi inversé la logique du signal du bouton (j'ai enlevé le not devant le pin11).
Électriquement tout est resté pareil.
Je vais jeter un oeil sur la logique du bouton, je sais plus s'il interrompt la ligne mise au ground, ou au contraire ...
En tout cas j'ai résolu mon problème de démarrage à l'ouverture du fichier, même si ça reste pas très clair pourquoi ...
Oui je viens de vérifier, quand ton signal de bouton est inversé, c'est à dire normalement true 1 et passant à false 0
quand il est actionné, il se reproduit le même phénomène.
Quand le fichier est chargé, il démarre sur un front montant, donc quand on relâche le bouton.
Après le chargement d'un fichier, il démarre en scrutant l'état du bouton, donc normalement true.
Pense à utiliser Hal mètre, il permet de sonder les états ainsi que toutes las valeurs numériques comme
une sorte de multimètre. et Hal scope aussi mais qui demande un peu de prise en main comme tout oscilloscope.