open embroidery

[OlivierVSL]

Je ne suis pas programmeur pour un clou mais j'arriverai peut-être à convaincre quelqu'un de chez nous pour regarder à cela avec moi... (bon, c'est pas gagné mais l'espoir fait vivre )

Quel est le language de programation du soft ?

[3dsman]

C'est tout en c++ avec QT pour l'interface et de l'opengl pour la vue mais du coup pour faire un exporteur c'est full c++ (avec un micropoil de Qt pour la com serie)

[johan]

hello! je suis un ami d'OLivier qui m'a montré votre projet. je me sens motivé pour faire un export Gcode et peut etre plus par après...
QT et c++ ?

est-ce que ça vous intéresse de collaborer?

merci

JOhan

[3dsman]

Salut Johan!
Je n'ai qu'un mot: "super"
On devrait ouvrir le dépôt gitlab sous peu.
Si tu as déjà joué avec git tu devrais savoir quoi faire a partir de la
Il y a 2 possibilité pour le gcode: un exporteur (le plus simple a faire pour commencer) ou un deuxième module de pilotage de machine (envois du gcode par le port série en live)
La deuxième option offre l'avantage du suivi de la broderie sur l'ordi, la possibilité de mettre en pause, gérer la vitesse de broderie en dynamique,... Mais forcément c'est un peu plus de travail

L'exporteur ça va être d'autant plus simple que Raoul viens d'isoler les exports dans de fichiers spécifiques.
En principe donc tu n'auras qu'un fichier à écrire

Envoie moi ton mail par mp, je te préviens quand on ouvre le dépôt (le système de suivi des threads par mail est un peu HS en ce moment)

[Flax]

Déterrage de thread !

Vu qu'on en a discuté ce week-end avec 3DS, je vais tenter de mettre un orteil dans le projet pour filer un coup de main sur la carte de commande.

Je vais déjà tâcher de fabriquer une carte, et en profiter pour améliorer le routage. Parce que bon ... je vois plein de problèmes (plein de petits, quelques gros), et pas du tout parce que je suis maniaque, pas du tout, n'allez pas croire ça voyons.
Déjà, quelles sont les contraintes mécaniques ? Y-a-t'il des emplacements précis pour les connecteurs ? Ça serrait bien de dessiner le contour du PCB et les emplacements explicites des connecteurs dans un logiciel de CAD, et ensuite l'importer dans Kicad, ça me semble plus propre et gérable. Sinon on a aucune idée des contraintes.
Idéalement les trous de fixation devraient avoir des symboles sur le schéma. Je les ajouterai dans mes modifs.
Et il faudrait qu'il y ait un marquage sur la carte, au moins en sérigraphie, idéalement dans le cuivre, avec la ref et la révision, pour pouvoir identifier. Ça aussi je l'ajouterai.
Pourquoi est-ce que l'entrée de référence ADC n'est connectée que sur un seul des deux drivers ?
Pourquoi est-ce que les CSn sont reliés ensemble sur les deux drivers ? Ça serait mieux de les contrôler séparément, non ? Il y a encore des pins dispo sur le MCU.
Les symboles de condensateurs non-polarisés avec des empreintes de condensateurs polarisés, ça par contre je ne veux pas entendre de justification, ça ne se fait pas >(
Est-ce que le module BT est obligatoire pour pouvoir faire fonctionner la carte ? Parce que le HC-05 n'est pas vendu par Mouser donc je ne peux pas le mettre dans ma commande

Samedi j'avais évoqué l'éventualité d'une double implantation avec un Arduino + Pololu, mais vu la méca ça me semble très compliqué, il n'y a vraiment pas assez de place pour tout faire rentrer sur le PCB. Par contre, je reste persuadé qu'avoir une électronique alternative en Arduino + Pololu serait pas mal, pour laisser de la souplesse. Mais bon, c'est du nice-to-have.

Mon idée pour mettre le pied dedans ça serait de faire un projet basique avec le LL ST, pour voir si j'arrive à faire des commandes basiques sur les moteurs. Mais il faudrait surtout que j'attrape Roul pour avoir le firmware en l'état et voir comment je peux aider dessus.
D'ailleurs, vu qu'il n'y a aucun code publié d'aucune sorte, même sur les anciennes versions de proto, je me demandais s'il ne serait pas possible de faire un commit "lite" / non-fonctionnel du code actuel expurgé des fonctions non-publiables (remplacées par des stubbs) ? De façon à avoir un truc qui compile et qui tourne même s'il manque des fonctions, mais qu'au moins il y ait une "archi de travail" disponible.

Voilà voilà. Merci d'avance

[Flax]

Merci à Raoul qui m'a donné accès au repo avec le firmware
J'avoue j'ai un peu mis ce sujet de côté, j'ai mis en priorité mon projet à moi qui attend depuis trop longtemps :p Ceci-dit, voici déjà quelques remarques après avoir jeté un oeil.

Le fichier IOC n'est plus compatible avec les versions récentes de STM32CubeIDE. J'ai la 15.1 et il ne veut même pas l'ouvrir, il me conseille de sortir une vieille version bon, l'avantage c'est que c'est du plain-text, xml-like, donc je devrais réussir à "forger" un IOC compatible avec les versions récentes. Je m'occupe de faire ça.

Ça manque de commentaires je trouve je me propose d'ajouter des commentaires et de documenter autant que possible.

Il y a beaucoup d'opérations logiques qui sont faites sans parenthèses. Je comprends le besoin de ne pas alourdir, et le fait que le C a l'avantage d'avoir une syntaxe très déterministe et des règles d'association sans ambiguïté, cependant personnellement je préfère toujours avoir des parenthèses, parce qu'une erreur est vite arrivée si on ne fait pas gaffe, et autant ne pas se mettre des bâtons dans les roues, ya déjà suffisamment de problèmes comme ça.

Beaucoup de magic numbers :p Pareil : je me propose de transformer ça en constantes / macros pour clarifier.

Sinon rien de spécial à dire, surtout des remarques "cosmétiques" parce que je suis maniaque. A suivre ...