CN migration OS

@Thomas

Pourrions nous nous voir pour la traduction du hal.file? Je n’arrive meme pas a activer le bouton toggle machine power qui reste inactif. En principe ce bouton est inactif lorsque le bouton emergency stop est enfoncé mais je n’arrive pas a declarer l’emergency stop sur une I/O.

alors que ca devrait etre (bouton orange)

page 8 du Pico Data Sheet :
<< VSYS is the main system input voltage, which can vary in the allowed range 1.8V to 5.5V, and is used by the on-board SMPS to generate the 3.3V for the RP2350 and its GPIO.
3V3_EN connects to the on-board SMPS enable pin, and is pulled high (to VSYS) via a 100kΩ resistor. To disable the 3.3V (which also de-powers the RP2350), short this pin low.
3V3 is the main 3.3V supply to RP2350 and its I/O, generated by the on-board SMPS >>

Sur la planche page 23 « plan électrique » du Pico, tout est en 3,3V

Bonjour, Si vous avez des problèmes d’adaptation 3.3V vers 5V, j’ai en stock des petits modules chinois, je peux vous en donner quelques-uns. Sinon, si vous avez besoin d’une isolation galvanique on peut utiliser des optocoupleurs. N’hésitez pas à revenir vers moi en cas de besoin.

Frédéric

Il est vrai que l’isolation par optocoupleurs est :ok_hand:
Mais bon, avec 2 malheureuses résistances, ça marche aussi :rofl:, surtout si on n’a que 2 infos !!!

on doit avoir 2 infos pour le X, une info pour le Y, une info pour le Z et une info pour l’arrêt d’urgence , ca qui donne 5 infos

c’est vrai que ça : Carte d'Isolation Optocoupleur,8 Canaux Module d'Isolation Optocoupleur DC 3.3V 5V PNP NPN Convertisseur de Signal de Sortie de Bas Niveau Elevé : Amazon.fr: Commerce, Industrie et Science
c’est trop facile à faire :laughing:

Y a meme des jours ou il y a un palpeur :slight_smile: sans compter les dir et step (2 signaux) pour chacun des moteurs.

@thomas : voici les .ini et .hal de la machine recuperes hier.

fraiseuse.zip (3,6 Ko)

L’intérêt de mon petit module est lorsque les signaux doivent circuler dans les 2 sens, si dans un seul sens, 5v vers 3.3v une résistance et une zener par sécurité suffisent largement… Au vu du prix ridicule de ces petits modules, inutile de les réaliser soit même, les prendre tout faits, idem pour le module avec les optocoupleurs.

Le problème est que thomas avait prévu dans la conception de la carte qu on enlève les 2 cordons parallèles et a la place, sans rien changer au cablage, on mette nos 2 petites cartes équipées de connecteur db25 câbles pour rétablir les mêmes liaisons. Et ça c est un vrai plus vu que nous avions refait le câblage de la machine très proprement et que nous n avons pas trop envie de mettre de la tripaille au milieu. Si il y a une chance que ça marche en 5V selon ce que dit la datasheet, il faut sans doute explorer avant d abandonner le 5V.

Je viens d’essayer de convertir les fichiers de la CN pour que cela fonctionne avec les nouvelles cartes.

Ci dessous les nouveaux fichiers
fraiseuse_new.zip (3,2 Ko)

J’ai réussi à lancer LinuxCNC avec cette config. Je n’ai pas de carte donc, je ne peux pas aller plus loin.

Les numéros de GP dépendent de la configuration, il faudra probablement les modifier.

J’ai rajouté deux fonctions logique OU afin de combiner les signaux de l’arret d’urgence, stepgen-ninja.0.io-ready-out et stepgen-ninja.1.io-ready-out

Reste à faire :

  • Adapter les numéros de GPIO en fonction de la configuration finale des cartes
  • Vérifier in situ que ça marche

On tient le bon bout :laughing:

C’est vrai que c’est le top

Tensions pico :warning:

Paragraphe 4-2

Là encore , sur « passion électronique »

…. * tester la présence ou non d’une tension provenant de l’USB, pour savoir si un câble USB est branché ou non sur le Pico (la broche testant cela est la GPIO 24) ; ce test se fait au travers d’un pont résistif, qui, à partir du +5V USB qu’on retrouve sur la ligne Vbus, nous donne, en sortie de pont, du +3,2 volts environ (indispensable pour attaquer le MCU RP2040, qui ne supporte pas plus de 3,3 volts).

Partout, dans ce que j’ai pu lire ou voir, les entrées du pico sont en direct sur le chip du micro et de ce fait ne doivent pas dépasser 3,3V :double_exclamation_mark:

pour moi ca plante

il y a une gp28 qui n’existe pas ca c’est pas grave, c’etait la probe, je l’ai commentée en attendant de la definir, par contre ligne 91 il y a cette erreur et je ne peux rien faire car je ne comprends pas quel en est le but.

‹ stepgen-ninja.0.io-ready-out › was already linked to signal ‹ condition2 ›

J’ai commenté la ligne qui plantait, et la j’arrive a peu pret au meme point ou j’en était la semaine derniere. Le bouton permettant de demarrer la machine est inactif. J’ai supposé que c’est lie au e-stop qui ne doit pas etre dans le bon etat alors j’ai changé

net estop-ext-raw <= stepgen-ninja.1.input.gp26

par

net estop-ext-raw <= stepgen-ninja.1.input.gp26-not

mais ca n’a rien changé

Aah les modif’ de dernière minute à la volé non testé :sweat_smile: Un copier/merder

J’ai fais les modif’, je les ai entièrement testé
fraiseuse.hal (3,8 Ko)

Je pense que le problème vient de là, mais aussi un peu du fait que j’avais codé une fonction logique OU au lieu de ET pour l’agrégation de toutes les conditions.
Car, sauf encore erreur de ma part :sweat_smile:, maintenant pour autoriser la mise sous tension, il faut qu’il n’y ait pas d’arret d’urgence (bouton câblé en normalement fermé) et que les deux cartes stepper-ninja soit ready.
Ce qui donne le code si dessous dans le fichier hal

net condition1 logic.0.in-00 <= debounce.0.0.out
net condition2 logic.0.in-01 <= stepgen-ninja.0.io-ready-out
net condition3 logic.0.in-02 <= stepgen-ninja.1.io-ready-out
net estop-ext iocontrol.0.emc-enable-in <= logic.0.and

debounce.0.0.out étant la sortie de la fonction debounce correspondant à l’arrêt d’urgence.

Du coup si toutes ces conditions ne sont pas rempli, ça ne pourra pas démarrer.
Si nécessaire la doc de la fonction logic, pour adapter le code au cas particulier

Il faut regarder dans LinuxCNC>Machine>Show Hal Configuration>Pins>stepgen-ninja>0>input les entrées existantes. Celle ci proviennent normalement du config.h utilisé pour la compilation du firmware

:face_with_monocle: :thinking: :roll_eyes: :face_with_thermometer: :star_struck: :smiling_face_with_three_hearts: :smiling_face:

Un peu d’info sur le sujet.

Je dois avouer qu’après presque 6 mois passés sur le sujet, je commençais a perdre confiance non pas sur l’atteinte du résultat, mais plutôt sur la maintenabilité de la solution Ninja. En clair je me sentais de moins en moins confiant pour assurer le support de cette solution.

J’ai donc voulu tester la solution « mesa » plus standard car supportée par l’outil de configuration pncconf de LinuxCNC.

J’ai commandé une première carte qui était buguée mais en fait, juste avant de la renvoyer chez ali, je me suis aperçu que le Firmware original chargée sur la carte était buguée, mais en chargeant un Firmware trouvé sur le site mesa, le bug disparaissait. C’était trop tard, j’avais demandé le remboursement et fait le bon de retour.

J’en ai donc commandé une autre 70€ et celle-là est arrivée sans Firmware du tout, mais j’avais appris lors du premier test. J’ai donc chargé le bon Firmware trouvé sur le site mesa et pour le moment avec l’outil pncconf je n’ai rencontré aucune galère. La carte est sur ma machine, les 6 moteurs tournent, la carte est en 5V natif, J’ai dû arrêter la progression car je me suis aperçu que le boitier de fin de course d’un de mes 2 axes Z était cassé, il faut que je le réimprime et que je le change.

A ce jour, les 6 moteurs tournent, j’ai pu prendre les origines sur X(2 moteurs) et Y (1 moteur), mais pas sur Z en raison du PB expliqué plus haut. Il me manque :

  • réparer mon boitier fin de course en Z

  • intégrer le variateur de vitesse de la broche (je ne pense pas que ce soit un problème)

  • intégrer le pendant, j’espère que ce sera comme le reste mais à voir.

  • tester la machine en condition réelle.

Si tout va bien sur ma machine, je proposerai cette solution en régulectif.

1 « J'aime »

Trop trop fort et quelle abnégation :face_with_tongue::clap: