jedicut.com

J'ai repris aujourd'hui le développement d'un programme similaire à GRBL mais spécialement orienté pour une machine de découpe au fil chaud (4 axes, vitesse constante, chauffe réglable) (alors que GRBL est plus orienté CNC).
Ce programme est beaucoup plus simple que GRBL car il ne gère pas les accélérations.
Je ne pense pas que cela soit un problème pour une machine à fil chaud avec des nema 17 car la vitesse atteinte sans accélération est largement suffisante.
Par contre, cela a comme avantage d'avoir une vitesse du fil plus constante et ce même si les points sont plus rapprochés les uns des autres.
Ce programme a aussi pour avantage de ne pas nécessité de carte intermédiaire entre l'arduino et la ramp. On peut directement enficher la ramp dans l'arduino car le programme permet de choisir librement les pins utilisées pour commander les moteurs.
La configuration actuelle dans le programme a été choisie pour être compatible avec celle utilisée par Aeroden.

De par sa simplicité (relative), ce programme peut facilement être adapté par d'autres personnes.

Le programme a été prévu pour gérer (en option) des fins de course et permettre facilement un retour automatique à une position de référence.
Si les fins de course MIN sont utilisés, le principe est le suivant: On lance une commande avec de grands déplacements. Les moteurs se mettent en route.
Indépendamment les uns des autres, chaque moteur cesse de fonctionner dès que le fin de course correspondant à son axe est activé. Donc les 4 moteurs retournent à leur position de référence.
Même si un fin de course est activé, on peut envoyer (et faire exécuter) des commandes de déplacement dans la direction opposée.
On peut donc lancer une découpe immédiatement après un retour à la position de référence.

La chauffe est gérée de sorte que les commandes de changement de chauffe sont exécutées non pas immédiatement (comme GRBL) mais en respectant leur position par rapport aux commandes de déplacement.

Je n'ai pas de machine actuellement pour tester le programme.

Si certains d'entre vous veulent le tester, je peux fournir le code et donner quelques explications supplémentaires.

A noter que de nombreuses améliorations sont encore possibles:
- permettre d'utiliser des inters pour par exemple arrêter la chauffe, la forcer au max (nettoyage du fil)
- paramétrer les sens de rotation des moteurs, la position des fins de course MIN
- mémoriser une vitesse pour les commandes G0 (déplacement rapide)
- supporter des commandes permettant de modifier les paramètres de la machine (nbr de pas, micropas, mm/tour, ...) et pouvoir les sauver en eeprom
- supporter des fins de course MAX (qui provoquerait l'arrêt de la machine)
- gérer des fins de courses logicielles (lorsque les fins de course matérielles ne sont pas implémentées)
- ....

Bonsoir mstrens

Je peux tester ton programme, si tu le souhaite.
j'ai déjà modifier le skech fcaldenmega pour jedicut en ajoutant les dégagements de fin de course, qui ne sont pas chainé tous en série, j'en ai profié pour faire une sorte de POM.

Vince

Je viens de mettre les fichiers sur Github à :
https://github.com/mstrens/GCode-interpreter-4-axis

Ceci n'est qu'une beta version pour des tests.
J'ai fait quelques test avec un seul moteur (axe X) et cela semblait OK.

La liste des commandes disponibles est affichée sur le terminal serie au démarrage.

Il est toutefois possible (probable) qu'il faille rapidement ajouter la possibilité de configurer le sens de déplacement des moteurs, le fait que les fins de course soient en normalement ouvert ou en normalement fermé et le fait qu'ils soient en fin de direction positive ou négative.
Actuellement cela est hard codé. Prudence donc si on lance le programme sur une machine réelle.

Pour les moteurs, le programme utilise le même cablage que Aeroden
Gcode X = axe X1 = driver marqué X sur la Ramp
Gcode Y = axe Y1 = driver marqué E0 sur la Ramp
Gcode Z = axe X2 = driver marqué Y sur la Ramp
Gcode U = axe Y2 = driver marqué E1 sur la Ramp

Pour les fins de course MIN (ceux qui permettent la mise à une position de référence), j'ai modifié légèrement pour toujours utiliser des external interrupts
- Fin de course X1 = pin Signal de la ramp le plus proche du driver E1 (idem Aeroden)
- Fin de course Y1 = pin Signal suivant (en s'éloignant de E1) (idem Aeroden)
NB : les 2 pins Signal ne sont pas utilisées (contrairement à Aeroden)
- Fin de course X2 = Pin signal suivant de la ramp
- Fin de course Y2 = Pin signal suivant de la ramp (donc le plus éloigné de E1)

J'utilise des résistances pull up interne à l'arduino.
La détection se fait donc par mise à la masse.
Actuellement le programme utilise la logique normalement ouvert donc:
- quand on n'est pas en fin de course, l'inter est ouvert et la tension lue par l'arduino est High.
- quand on est en fin de course, l'inter met le signal à la masse et l'arduino lit un niveau LOW.
Il est simple de changer la logique si on veut.
En cas de fin de course détectée, le programme ne génère plus de signal Step sur l'axe concerné si et seulement le mouvement est dans une direction déterminée (actuellement ceux demandant un mouvement positif). Il serait sans doute plus naturel de faire l'inverse mais je n'ai pas eu le temps de changer.

Si quelque chose n'est pas clair, n'hésites pas demander.

Je viens de mettre une nouvelle version sur github qui doit en principe (non testé) permettre via des paramètres :
- de changer le sens de rotation des moteurs
- de changer le mode de fonctionnement des fins de de course (logique normalement ouverte ou fermée)
- de changer la direction correspondant aux fins de course MIN (permet de mettre la position de référence à une extrémité ou à l'autre)

j'ai aussi corrigé un petit bug sur l'axe U.

Bonjour,

Super ton initiative, bonne continuation.

Bonjour,
@ mstrens
Bravo pour ton initiative, je suis désolé, je ne vais pas testé ton sketch car j'ai terminé la mise au point de Grbl-Alden qui donne entière satisfaction et maintenant je vais construire des avions.

La chauffe est gérée de sorte que les commandes de changement de chauffe sont exécutées non pas immédiatement (comme GRBL) mais en respectant leur position par rapport aux commandes de déplacement.

La version actuellement en téléchargement bénéficie de la synchronisation de la chauffe pour chaque segment.
Bon courage.
Alain

Je viens de mettre sur github une nouvelle version du programme.
J'ai eu l'occasion de faire des tests ce matin et j'ai corrigé quelques bugs.
Sur base de mes tests:
- les 4 moteurs tournent correctement en réponse à des commande G1
- les fins de courses ont l'effet prévu (Ils empêchent de dépasser la position limite mais ne bloque pas les mouvements dans la direction opposée); ils fonctionnent en normalement ouverts ou normalement fermés (suivant le paramétrage choisi).
J'ai ajouté quelques commentaires explicatifs dans le fichier de configuration.

Le programme essaie de simuler GRBL pour être compatible avec des contrôleurs conçus pour envoyer des commandes à un arduino avec GRBL.
Ainsi au démarrage mon programme se déclare être Grbl 1.1f.
Il répond à des commandes CTRL-X (soft reset) et à ? (donner la position des axes de la machine).

A noter que dans cette version, les mouvements "rapides" commandés par G0 se font encore à la même vitesse que ceux à la vitesse lente (commandés par G1).
Il est certainement possible d'apporter encore pas mal de fonctionnalités supplémentaires (fins de course max, sauvegarde de paramètres en eeprom, vitesse différente pour G0 et G1, prises en compte d'inter supplémentaires pour "forcer" la chauffe ou moteurON/OFF, prise en compte d'une carte SD, gestion d'un affichage,...).
A noter qu'il est peut-être plus simple d'ajouter des fonctionnalités à ce code que de se lancer dans la modification de Marlin.

Comme déjà signalé, je pense que ce programme est mieux à même de traiter des découpes avec de nombreux points rapprochés en gardant une vitesse constante que GRBL. Je ne l'ai toutefois pas vérifié par moi-meme.

Je ne prévois toutefois de faire des développements supplémentaires que s'il y a de réelles demandes.
Personnellement, je pense que cette version répond à mes besoins.
S'il y a des bugs rapportés ils seront bien sûr corrigés.

Bonjour mstrens

Je viens de tester la nouvelle version, le dialogue avec GRBL controller 3.6.1-T4 fonctionne (mise a part le retour des positions pas important pour l’instant), mais aucune de mes moteurs de fonctionne . J'ai un montage aeroden Mega + ramps, cela fonctionne bien avec jedicut et même avec un GRBL dénicher sur le net (sans carte d'adaptation).

Je vois que cela bosse pour améliorer ton "GRBL"

Vince

Pour déterminer si c'est le contrôleur GRBL qui pose problème ou autre chose, peux tu lancer des commandes directement du PC terminal de l'arduino IDE?
Pour cela quand l'arduino IDE est démarré, il faut sélectionner le bon Port de communication (comme pour chargé le programme dans l'arduino) et presser simultanément sur CTRL + Shift + M
Cela ouvre un terminal serial.
Vérifies (en bas que la vitesse est la bonne (115200) et que le retour charriot (ou retour chariot + nouvelle ligne est activé).
En principe au démarrage, l'arduino doit envoyer le texte Grbl1.1f ['$' for help] (ou quelque chose d'approchant).

Après avoir cliqué dans la zone d'entrée, tu peux entrer des commandes.
En principe pour faire bouger les moteurs, il faut d'abord les activer (en envoyant la commande M17 + enter).
Ensuite tu peux taper des commandes comme G1 X10 et le moteur X devrait bouger.
En fonction du paramétrage des fins de course, il est possible qu'il faille donner une commande dans la direction opposée (G1 X-10)

J'ai eu des problèmes avec certains contrôleurs GRBL. Tous ne réagissent pas de la même manière et certains attendent peut-être des réponses à des commandes que ma version ne supporte pas.

Salut mstrens,

Superbe initiative ! Continue à développer ta solution même sans utilisateur, c'est comme ça que naissent les grands projets