Page 1 sur 2

Marlin et Jedicut ??

Posté : lun. févr. 19, 2018 9:03 pm
par Zob
Salut,

Avec Vincent, Hugo et Seb, on s'est dit que quitte a utiliser une Ramps avec un écran et un lecteur SD, pourquoi ne pas profiter de Marlin qui gère déjà le Gcode et la carte SD pour des découpe sans PC.

Jedicut pouvant déjà générer du Gcode, on s'est dit que ça devait être possible, alors on a cherché plus en profondeur.

1er problème, JDC génère du Gcode pour GRBL et non Marlin, bien que Marlin soit tiré de GRBL, ce ne sont pas les mêmes protocoles ...
J'ai donc modifié Marlin pour qu'il accepte le Gcode GRBL, très succinctement, seulement pour les déplacements G0 G1 et quelques autres trames nécessaire comme vitesse et chauffe.

Nous avons donc fait un premier test en essayant de piloter la Ramps depuis Jedicut, ne sachant pas que le contrôle ne se faisait pas par Jedicut mais par GRBL Controller Visualizer, nous avons donc généré du Gcode que nous avons mis sur carte SD. Nous avons donc testé et ... Miracle, le Gcode a fonctionné ... vient maintenant le
2eme problème, comme pour GRBL avant que Aeroden ne le modifie, Marlin ne gère seulement que X , Y, Z et E l'extrudeur des imprimantes 3D. L'axe Y2 qui était connecté sur le Driver E n'a pas fonctionné car je soupçonne Marlin d'avoir des sécurités pour empêcher l'extrusion a froid du filament (bien que dans les configs j'ai désactivé ces protections...). Il va donc falloir comme pour GRBL modifié la gestion de X,Y, Z et E pour une gestion X1, Y1, X2, Y2, ce qui ne devrait pas être trop compliqué ... Peut-être :-)

Un truc sympa aussi avec Marlin, c'est qu'avec les menus du LCD, il a était possible de déplacer les moteurs directement depuis le LCD avec l'encodeur.

J'ai essayé par la suite de contrôler depuis GCV (GRBL Controler Visualizer) mais le protocole n'étant pas le même, GCV ne garde pas le port Com ouvert si il ne reçoit pas une trame réponse de la Ramps au démarrage (Je suppose).

Nous avons pour l'instant stoppé le développement car nous sommes un peu "déçu qu'il faille 2 Softs (Jedicut et GCV) pour le contrôle de la machine ...
Est-ce qu'une gestion du port série en direct par Jedicut serait envisageable ???? Le port Parallèle étant de plus en plus obsolète ...

Cordialement,

Olivier.

Re: Marlin et Jedicut ??

Posté : mar. févr. 20, 2018 7:46 am
par Jerome
Salut et bienvenue !

Je vais me documenter sur ce Marlin pour comprendre de quoi tu parles :?

Le GCode est un langage, et dans Jedicut j'ai essayé au maximum de le rendre "paramétrable" pour qu'il soit compatible avec un maximum de logiciel ou machine. Bien sur je n'ai couvert qu'une fraction des possibilités.

Pourrais tu décrire les principaux écarts entre le GCode GRBL et le GCode Marlin ? Ce n'est peut être pas compliqué à faire évoluer ?

Concernant ta dernière question, je suis d'accord avec toi, on pourrait trouver une solution pour que Jedicut envoie lui même le GCode à la machine. Dans ce cas on retourne sur une question de "communication", et il faut développer un plugin en faisant évoluer le plugin GCode (et surement quelques modif dans Jedicut pour rajouter une étape d'envoi d'instruction sur les ports après la génération du fichier). Pour ne pas réinventer la roue, il faudrait trouver une librairie de communication compatible USB qui sache envoyer du GCode à un Arduino, ou s'inspirer des nombreux projets open source qui font ça. ça pourrait demander pas mal de travail, et il y en a plein dans la todo list. Mais je suis d'accord : ce serait top si Jedicut savait envoyer lui même son GCode :D

Il y aura peut être un volontaire pour travailler sur ce plugin ? ::friends::

Re: Marlin et Jedicut ??

Posté : mar. févr. 20, 2018 8:13 am
par modelvincent
La question que je me pose c'est la génération du gcode par jedicut, actuellement ça fait partie du noyau ? Parce que je n'ai rien trouvé dans le plugin gcode sur github sur la partie génération du fichier ?

Je ne regarde peut être pas au bon endroit?

La partie communication après en se basant sur le même principe qu'usb serial ça ne serait pas insurmontable à mon avis...

Re: Marlin et Jedicut ??

Posté : mar. févr. 20, 2018 9:10 am
par mstrens
Pour info, il existe 2 manières classiques pour envoyer du Gcode à Grbl.
Une "simple" : elle consiste à envoyer une ligne de commande et à attendre que Grbl ait renvoyé "OK" avant d'envoyer la ligne suivante.
Si les tronçons sont courts, cette méthode ne marche pas bien car elle va provoquer beaucoup de changements de vitesses ce qui est très mauvais pour une découpe au fil chaud.

Une plus complexe qui consiste à envoyer plusieurs lignes sur le port série en veillant à ne pas saturer le buffer dans Grbl. Pour cela compte le nombre de lignes envoyées et qui n'ont pas encore fait l'objet d'un "OK" .
Cette méthode réduit le risque de changement de vitesse car le buffer de Grbl est mieux rempli ce qui permet à Grbl de mieux pré-calculer les changements d'accélérations.
A noter que si les tronçons sont très courts, GRBL n'est malgré tout pas capable de respecter une vitesse constante (même avec un setup prévoyant une accélération énorme) car le CPU n'est pas capable d'effectuer tous ses recalculs assez vite.
La solution est alors de réécrire Grbl pour supprimer tout ce qui concerne les accélérations.
Si quelqu'un est intéressé, je peux envoyer la version de Grbl que j'ai réécrite (mais qui n'est 100% finalisée).
Le code est considérablement plus simple à comprendre et donc à étendre (par exemple pour implémenter les fins de courses,...).
Il permet aussi d'exploiter n'importe quelle pin de l'arduino ce qui évite une carte intermédiaire entre arduino et ramp.

Pour info voici le programme python qui gère la manière la plus efficace de communiquer (c'est juste trouvé sur le net).
C'est facile à implémenter dans un autre langage.

#!/usr/bin/env python
"""\

Stream g-code to grbl controller

This script differs from the simple_stream.py script by
tracking the number of characters in grbl's serial read
buffer. This allows grbl to fetch the next line directly
from the serial buffer and does not have to wait for a
response from the computer. This effectively adds another
buffer layer to prevent buffer starvation.

CHANGELOG:
- 20140714: Updated baud rate to 115200. Added a settings
write mode via simple streaming method. MIT-licensed.

TODO:
- Add runtime command capabilities

---------------------
The MIT License (MIT)

Copyright (c) 2012-2014 Sungeun K. Jeon

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
---------------------
"""

import serial
import re
import time
import sys
import argparse
# import threading

RX_BUFFER_SIZE = 128

# Define command line argument interface
parser = argparse.ArgumentParser(description='Stream g-code file to grbl. (pySerial and argparse libraries required)')
parser.add_argument('gcode_file', type=argparse.FileType('r'),
help='g-code filename to be streamed')
parser.add_argument('device_file',
help='serial device path')
parser.add_argument('-q','--quiet',action='store_true', default=False,
help='suppress output text')
parser.add_argument('-s','--settings',action='store_true', default=False,
help='settings write mode')
args = parser.parse_args()

# Periodic timer to query for status reports
# TODO: Need to track down why this doesn't restart consistently before a release.
# def periodic():
# s.write('?')
# t = threading.Timer(0.1, periodic) # In seconds
# t.start()

# Initialize
s = serial.Serial(args.device_file,115200)
f = args.gcode_file
verbose = True
if args.quiet : verbose = False
settings_mode = False
if args.settings : settings_mode = True

# Wake up grbl
print "Initializing grbl..."
s.write("\r\n\r\n")

# Wait for grbl to initialize and flush startup text in serial input
time.sleep(2)
s.flushInput()

# Stream g-code to grbl
l_count = 0
if settings_mode:
# Send settings file via simple call-response streaming method. Settings must be streamed
# in this manner since the EEPROM accessing cycles shut-off the serial interrupt.
print "SETTINGS MODE: Streaming", args.gcode_file.name, " to ", args.device_file
for line in f:
l_count += 1 # Iterate line counter
# l_block = re.sub('\s|\(.*?\)','',line).upper() # Strip comments/spaces/new line and capitalize
l_block = line.strip() # Strip all EOL characters for consistency
if verbose: print 'SND: ' + str(l_count) + ':' + l_block,
s.write(l_block + '\n') # Send g-code block to grbl
grbl_out = s.readline().strip() # Wait for grbl response with carriage return
if verbose: print 'REC:',grbl_out
else:
# Send g-code program via a more agressive streaming protocol that forces characters into
# Grbl's serial read buffer to ensure Grbl has immediate access to the next g-code command
# rather than wait for the call-response serial protocol to finish. This is done by careful
# counting of the number of characters sent by the streamer to Grbl and tracking Grbl's
# responses, such that we never overflow Grbl's serial read buffer.
g_count = 0
c_line = []
# periodic() # Start status report periodic timer
for line in f:
l_count += 1 # Iterate line counter
# l_block = re.sub('\s|\(.*?\)','',line).upper() # Strip comments/spaces/new line and capitalize
l_block = line.strip()
c_line.append(len(l_block)+1) # Track number of characters in grbl serial read buffer
grbl_out = ''
while sum(c_line) >= RX_BUFFER_SIZE-1 | s.inWaiting() :
out_temp = s.readline().strip() # Wait for grbl response
if out_temp.find('ok') < 0 and out_temp.find('error') < 0 :
print " Debug: ",out_temp # Debug response
else :
grbl_out += out_temp;
g_count += 1 # Iterate g-code counter
grbl_out += str(g_count); # Add line finished indicator
del c_line[0] # Delete the block character count corresponding to the last 'ok'
if verbose: print "SND: " + str(l_count) + " : " + l_block,
s.write(l_block + '\n') # Send g-code block to grbl
if verbose : print "BUF:",str(sum(c_line)),"REC:",grbl_out

# Wait for user input after streaming is completed
print "G-code streaming finished!\n"
print "WARNING: Wait until grbl completes buffered g-code blocks before exiting."
raw_input(" Press <Enter> to exit and disable grbl.")

# Close file and serial port
f.close()
s.close()

Re: Marlin et Jedicut ??

Posté : mar. févr. 20, 2018 9:12 am
par Jerome
Salut,

J'ai fait évoluer le core de Jedicut pour prendre en compte un nouveau style de plugin de communication pour le GCode, mais l'ampleur de la tache était telle que j'ai mis l'essentiel du code de génération du GCode dans le core de Jedicut pour éviter d'empiler les sources d'erreurs.

Maintenant que le GCode fonctionne bien, il serait possible de travailler sur l'externalisation du code dans le plugin.

Et si tu as envie de bosser sur l'ajout du transfert du GCode vers Arduino, on peut travailler sur le sujet sans avoir à faire tout ce boulot je pense. Le GCode est produit dans un fichier, donc il faudrait définir la suite : l'envoi vers la machine en cohérence avec l'UI de Jedicut (fenêtre de confirmation de découpe, fenêtre de suivi de l'avancement...).

On a trouvé un volontaire ! Youpi ! :D

Re: Marlin et Jedicut ??

Posté : mar. févr. 20, 2018 11:29 am
par Zob
Dite moi si je me trompe mais Je pense que le mieux serait que le Port // soit aussi un plugin.
Le but serait que selon le mode de communication choisi, l'onglet communication permette la configuration du port, peut ête aussi du protocole.

Donc dans le cas d'un plugin port //, il y aurait la configuration des broches et de la fréquence comme ça l'est actuellement.
Dans le cas d'un port série, il y aurait la configuration du numèro de port ,de la vitesse et peut-être différent protocole de communication (ou différent plugin par protocole).
Dans le cas d'un port USB, je sais pas si il y aurait grand chose a configurer... plutôt une indication que la communication avec la carte soit établi ..

Bref que l'onglet communication présente seulement la configuration spécifique au port choisi.
Et que cet onglet soit "géré" par le plugin directement.

Re: Marlin et Jedicut ??

Posté : mer. févr. 21, 2018 7:19 am
par Jerome
Salut Zob,

La communication sur port parallèle ou port USB est déjà géré dans des plug in publié sur GitHub.

Ce qui n'est pas fait, et ça aussi c'est dans la todo (oui elle est grande :D ), c'est de personnaliser l'affichage des options en fonction du plugin de communication choisi. Par exemple si on choisit un plugin USB, alors l'image du port parallèle doit disparaitre, certains "pin" aussi, la mention "Port Parallèle" doit être remplacé par "USB"...

Mais pas encore eu le temps de me pencher sur le sujet, je voudrai régler les problèmes de la chauffe avant.

Tu soulèves aussi la question de gérer l'affichage directement dans le plugin. J'y est pensé, surtout pour le plugin GCode, mais ça demande aussi pas mal d'adaptation et de tests pour bien valider l'interface core / plugin, c'est pour ça que j'ai rapidement décidé de me concentrer sur l'essentiel lorsque j'ai bossé sur le GCode, à savoir faire en sorte que ça marche avant d'en faire un vrai plugin. Je suis souvent seul sur la programmation des plugins, donc là aussi ça ne me semble pas urgent.

Re: Marlin et Jedicut ??

Posté : mer. févr. 21, 2018 8:57 am
par modelvincent
C'est clair que pouvoir gérer un onglet de JDC directement depuis un plugin ça serait le top...

Après tu as peut être déjà répondu mais je n'ai rien trouvé mais pour quelle raison as tu fait le choix de garder le noyau de jedicut non Open-source alors que tout le reste l'est?

Ça te simplifierait la tâche car on pourrais t'aider aussi sur le noyau?

Re: Marlin et Jedicut ??

Posté : mer. févr. 21, 2018 1:04 pm
par bozzo 12
d'autant qu'il y a de notre coté, une dynamique qui pourrait mettre un petit coup d'accélérateur au programme, certains d'entre nous ne sont pas mauvais en programmation, et d'autre le sont plus pour tester et valider les avancées, c'est du moins notre cas depuis deux semaines

hugo

Re: Marlin et Jedicut ??

Posté : jeu. févr. 22, 2018 8:37 am
par Jerome
Salut,

A une époque je me suis posé la question d'ouvrir entièrement le code. Et après recherche j'ai découvert des logiciels bien plus connus qui avaient fait machine arrière pour plein de raison : l'administration prend du temps, donner des explications prend du temps, documenter prend du temps... D'où l'intérêt d'externaliser un maximum de fonction dans des plugins.

J'ai déjà trouvé des membres motivés sur le forum. Le core de Jedicut étant hébergé sur un repo svn privé accessible depuis le net, j'ai fait le test de leur donner l'accès : Il ne s'est rien passé. Pas de code, pas de tests, pas de documentation du code... Collusion ou coïncidence, peu de temps après un membre du forum m'informe qu'un club diffuse un logiciel dont plusieurs images sont extraites de Jedicut... Pour en savoir plus il faudrait décompiler le programme. J'ai gentiment contacté son auteur pour connaitre ses sources d'inspiration, et il a fait l'ignorant. Il n'y a rien de grave là dedans, c'est la vie, et je ne gagne pas la mienne avec ça. Mais c'est quand même décevant.

J'ai aussi trouvé des personnes très motivées pour documenter Jedicut. A l'époque j'ai passé du temps à faire des recherches et j'ai finalement installé un wiki. Bilan ? Pas un mot écrit sur le wiki.

Il y a plein de fonctions que je souhaiterai externaliser et qui apporterait tout de suite un plus aux utilisateurs de Jedicut. Tant que je suis seul sur ces fonctions, je ne vais pas m'embêter avec des plugins. Si vous voulez m'aider et travailler dessus, directement sous forme de plugin, je pourrai faire évoluer le core pour implémenter l'appel à ces nouveaux plugins. On partout commencer comme ça, qu'en pensez vous ? Un autre avantage est que chacun peut utiliser le langage de programmationde son choix :)

Par exemple je verrai bien un plugin dédié à la manipulation des profils qui serait utilisé pour les découpes et les profils (DAT, JDC) pour :
- Revoir l'algorithme de calcul de la peau (l'actuel n'est pas génial),
- Calculer les caractéristiques aérodynamique du profil,
- Calculer des projections de profils dans un nouveau plan (pour les ailes à forte flèche, on pourrait tourner le bloc de poly comme l'explique Eric dans un message),
- Améliorer les calculs pour les longerons, et ajouter de nouveaux types de longeron,
- Calculer des évidements dans les profils.

Il y a aussi les plugins de fichier :
- Enregistrer un plugin DXF,
- Ouvrir des DXF : j'utilise la dll fournie pas un membre du projet IPL5X (l'auteur de la dll) mais je n'ai pas la doc, donc je ne l'utilise pas à fond.
- Ajouter le support d'autres formats de fichier.

Je bosserai avec plaisir avec vous sur ces plugins si vous êtes motivé :)-D Qu'en dites vous ?