je viens de faire la modif et aucun changement.
Bonsoir,
@LE TARTARE
Dans la version Grbl82Mega2560 - fichier config.h ne devrait-on pas commenter la ligne 50 ?
Bonsoir,
pour quelle raison ?
Re,
LETARTARE:
Bonsoir,
pour quelle raison ?
On utilise la même pin ligne 81
Bonjour,
@infobarquee
je viens de publier une version 0.83 qui prend en compte dans le fichier "config.h" le niveau actif voulu par l'utilisateur pour les sorties 6, 36, 37, 35
je l'ai testé sous Vista Pro pack2 en utilisant des relais actifs niveau 0 pour :
- Spindle Enable (br6) avec M3, M4, M5,
- Spindle Direction (br36) avec M3, M4,
- Coolant Flood (br37) avec M8, M9,
- Coolant Mist (br35) avec M7, M9
toutes ces sorties fonctionnent correctement et lors d'une RAZ sont toutes inactives.
Pouvez la tester ?
Bien cordialement.
@icare
la ligne "config.h:50"
// STEPPERS_DISABLE_INVERT: Set to 0 for active high stepper disable or 1
// for active low stepper disable.
#define STEPPERS_DISABLE_INVERT 0
ne sert pas pour adresser un bit d'un port, c'est une valeur utilisée comme masque sur une assignation de bit dans le fichier "stepper.c:90,95".
Si vous la commentez vous ne pourrez plus choisir le niveau actif associé à la commande des axes !!
Bonne nuit.
LETARTARE:
Bonjour,
@infobarquee
je viens de publier une version 0.83 qui prend en compte dans le fichier "config.h" le niveau actif voulu par l'utilisateur pour les sorties 6, 36, 37, 35
GitHub - LETARTARE/Mega2560-grbl: Free
je l'ai testé sous Vista Pro pack2 en utilisant des relais actifs niveau 0 pour :
- Spindle Enable (br6) avec M3, M4, M5,
- Spindle Direction (br36) avec M3, M4,
- Coolant Flood (br37) avec M8, M9,
- Coolant Mist (br35) avec M7, M9
toutes ces sorties fonctionnent correctement et lors d'une RAZ sont toutes inactives.
Pouvez la tester ?Bien cordialement.
je teste ca dans la matinée
Bonjour,
LETARTARE:
@icare
la ligne "config.h:50"// STEPPERS_DISABLE_INVERT: Set to 0 for active high stepper disable or 1
// for active low stepper disable.
#define STEPPERS_DISABLE_INVERT 0
ne sert pas pour adresser un bit d'un port, c'est une valeur utilisée comme masque sur une assignation de bit dans le fichier "stepper.c:90,95". Si vous la commentez vous ne pourrez plus choisir le niveau actif associé à la commande des axes !! Bonne nuit.
Autant pour moi.
Bonjour,
@LE TARTRARE
Toujours dans ma procédure de compréhension du code.
Dans le fichier gcode.cpp ne devrait-on pas mettre dans le switch(letter) ligne 256 la condition
default: FAIL(STATUS_UNSUPPORTED_STATEMENT);
pour éliminer les lettres non prévues.
@+
petit test rapide
ca a l'air de fonctionner, il faut que je test avec 4 moteurs pour voir
je viens de modifier pour avoir l'axe A au lieu de C, donc en relation avec l'axe X au lieu du Z
a tester, j'ai peut être zappé quelque chose, mais aucune erreur à la compile ni au test.
grbl0_83.zip (72.2 KB)
Bonjour,
@icare
Dans le fichier gcode.cpp ne devrait-on pas mettre dans le switch(letter) ligne 256 ...
je ne suis pas un expert de GRbl, je l'analyse en même temps que vous, surtout cette version qui est très ancienne (avril 2012) que j'avais récupérée à l'époque mais sans vraiment l'analyser. Il y a une grande distance avec la 0.8c actuelle (qui ne gère sur MEGA2560 que trois axes).
Je vais essayer de regarder, mais je pense qu'il existe encore des erreurs importantes dans cette version 0.81 et dérivées.
Mon objectif étant très pragmatique, je voudrai traiter préalablement toutes les entrées et sorties, avant d'analyser l'interprétation du GCode.
ca a l'air de fonctionner, il faut que je test avec 4 moteurs pour voir
c'est déjà une bonne nouvelle que cela fonctionne avec votre carte (laquelle ?), en fait il manquait dans l'initialisation de la carte le positionnement des 3 sorties (citées plus haut) au démarrage.
je viens de modifier pour avoir l'axe A au lieu de C,
bien, merçi pour le source, je vais le regarder.
Je crains que A ou C la corrélation avec l'axe d'origine n'existe pas, seuls des tests permettront de le dire.
Actuellement, je n'ai pas accès à mes machines et je ne peux faire que des tests assez simples, aussi si vous pouvez tester en vraie grandeur ce 4ème axe, ce serait très intéressant
Bien cordialement.
c'est déjà une bonne nouvelle que cela fonctionne avec votre carte (laquelle ?), en fait il manquait dans l'initialisation de la carte le positionnement des 3 sorties (citées plus haut) au démarrage.
en fait et avec l'aide d'Icare hier, on s'est rendu compte que le relais avait 2 positions sur ma carte et que par défaut le relais était en tension.
une position repos (led on sur la carte) et une travail (led off)
de plus je me suis gauffré comme un bleu en confondant la pwm6 et analog6 mea culpa ce qui expliquait le défaut sur M05
mais ta modif est des plus pertinente et me parait plus logique.
relais off = led off
relais on = led on
carte SainSmart CNC TB6560 4 Axes et une doc des plus minimaliste de surcroit.
bien, merçi pour le source, je vais le regarder.
Je crains que A ou C la corrélation avec l'axe d'origine n'existe pas, seuls des tests permettront de le dire.
Actuellement, je n'ai pas accès à mes machines et je ne peux faire que des tests assez simples, aussi si vous pouvez tester en vraie grandeur ce 4ème axe, ce serait très intéressant
il y a une corrélation dans une ligne dans un fichier, faudrait que je le retrouve
dans ta source
x traaille avec x
y travaille avec y
z travaille avec z
c travaille avec z
retrouvé 
dans limits.cpp
ma modif
if (a_axis) {
counter_a += steps[A_AXIS];
if (counter_x > 0) {
if (LIMIT_PIN & (1<<A_LIMIT_BIT)) { out_bits ^= (1<<A_STEP_BIT); }
else { a_axis = false; }
counter_a -= step_event_count;
}
}
au lieu de
if (c_axis) {
counter_c += steps[C_AXIS];
if (counter_z > 0) {
if (LIMIT_PIN & (1<<C_LIMIT_BIT)) { out_bits ^= (1<<C_STEP_BIT); }
else { c_axis = false; }
counter_c -= step_event_count;
}
}
Bonjour,
Si le 4ème axe est utilisé pour la rotation de la pièce, il n'y a pas de problème pour les tests.
L'axe C est utilisé pour les rotation autour de l'axe Z, ces positions sont accessible dans le plan XY.
Si on place le plateau tournant pour avoir une rotation autour de l'axe X donc, le fameux, axe A, on pourra utiliser le code pour l'axe C comme axe A (la conversion étant faite mécaniquement par le montage du plateau rotatif).
Pour les tests c'est suffisant à partir du moment où l'on sait ce que l'on fait
En exploitation des codes issues d'un convertisseur pièce vers gcode c'est autre chose, on n'est plus dans les tests.
@+
Bonjour,
Si le 4ème axe est utilisé pour la rotation de la pièce, il n'y a pas de problème pour les tests.
L'axe C est utilisé pour les rotation autour de l'axe Z, ces positions sont accessible dans le plan XY.
Si on place le plateau tournant pour avoir une rotation autour de l'axe X donc, le fameux, axe A, on pourra utiliser le code pour l'axe C comme axe A (la conversion étant faite mécaniquement par le montage du plateau rotatif).
Pour les tests c'est suffisant à partir du moment où l'on sait ce que l'on fait
En exploitation des codes issues d'un convertisseur pièce vers gcode c'est autre chose, on n'est plus dans les tests.
@+
@icare
je suis d'accord, si vous pouvez le faire ce serait très bien.
Je vais vérifier le fichier compressé fourni par infobarquée ...
A bientôt
Re,
Sans utilisé le 4ème axe, je viens de faire un essai avec la master version de GBRL ( GitHub - grbl/grbl: An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino )
pour l'utiliser directement dans l'IDE Arduino sans passer par makefile (makefile ne me pose pas de problème mais l'environnement Arduino est plus facile à mettre en oeuvre)
Le but de la manœuvre est, lors de modifications, de s'éloigner le moins possible de la version officielle de GBRL et faciliter ainsi les mises à jour perso par rapport à GBRL officielle.
Il suffit de créer un programme arduino standard :
#include "main.h"
void setup(){
main();
}
void loop(){}
De créer un fichier main.h
#ifndef __main_h
#define __main_h
int main();
#endif
De renommer tous les fichiers .c en .cpp
Maintenant, on compile avec l'environnement Arduino sans aucune modification des sources.
@+
@icare
vous avez déjà ces versions toutes faites en :
avec la version officielle 0.8c Uno, la version de développement 0.9d Uno et Mega2560.
Re,
LETARTARE:
@icare
vous avez déjà ces versions toutes faites en :
GitHub - LETARTARE/Grbl-xx_with_Arduino at master
avec la version officielle 0.8c Uno, la version de développement 0.9d Uno et Mega2560.
Oui, j'utilise ces versions dans mes tests actuels mais il y a beaucoup de divergences par rapport à GBRL originale.
Exact.
Je viens d'actualiser "Grbl_With_Arduino" avec
- "devArduino/0.83_0" pour mes modifications
- "devArduino/0.83_1" pour vos modifcations C -> A
GitHub - LETARTARE/Grbl-xx_with_Arduino at devArduino
pouvez-vous vérifier car je fais parfois des erreurs dans les mise à jour !!