Bienvenue aux nouveaux arrivants sur FantasPic !

- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.

--- L’équipe FantasPic ---
Forum général sur l'Assembleur !

Modérateur : mazertoc

Soft de commande CNC en asm
Temps-x
Avatar de l’utilisateur
Expert
Expert
Messages : 2595
Enregistré en : juillet 2016
Localisation : Terre

#51 Message par Temps-x » ven. 4 mai 2018 22:26

Bonjour F6FCO, satinas, et tous le forum

Petit programme que j'ai fait ICI, ça permets de tester sa RS232

Avant toute chose, toujours regardé si elle est fonctionnelle.

==> A+
Modifié en dernier par Temps-x le sam. 5 mai 2018 20:36, modifié 2 fois.
:roll: Les requins, c'est comme le langage ASM, c'est le sommet de la chaîne alimentaire. :wink:

Soft de commande CNC en asm
F6FCO
Avatar de l’utilisateur
Expert
Expert
Messages : 1413
Âge : 70
Enregistré en : décembre 2017
Localisation : Furtif je suis.
Contact :

#52 Message par F6FCO » ven. 4 mai 2018 23:41

Bonsoir tous,

satinas a écrit :La liaison série est la plus simple. Un logiciel comme TeraTerm permet d'envoyer un fichier brut sur le port série. Mais il faudrait tout de même un contrôle du transfert par checksum ou autre, et là il faudra peut être programmer sur PC aussi. Le contrôle de la communication est nécessaire afin d'éviter que le chariot aille se balader dans la pièce d'à côté ... Le checksum est aussi nécessaire pour la carte sd.


Oui j'ai découvert l'existence de Tera term ce matin en furetant sur le net, Windows aurait aussi un hyperterminal mais apparement moins performant. Mais c'est tout nouveau pour moi et il faut que je creuse davantage pour comprendre les finesses de la liaison RS232, jamais joué avec çà avant.
Voilà ce que j'ai cru comprendre, ceux qui connaissent me corrigeront si je dis des "concetés" :-D ,Tera term fait la liaison entre le port COM choisi et le fichier qui se trouve quelque part sur le disque dur. Mais il envoie le fichier via TX/RX d'un seul coup ce qui ne nous arrange pas, les PIC ayant une mémoire trop petite. Du coup il y aurait moyen de moduler le flux avec RTS et CTS.
J'ai bon ?
Une porte nand prend 2 bits en entrée... la cochonne !!! :langue:

Soft de commande CNC en asm
satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

#53 Message par satinas » sam. 5 mai 2018 05:54

Bonjour matinal,
La souplesse de la liaison série fait qu'elle est toujours là 50 ans après. Dans le cas du pic c'est très simple, 3 instructions machines pour émettre un octet sur tx, 3 autres pour recevoir sur rx. Et tout ça en full duplex.
Ca se complique si on traite les anomalies de transmission, il y a des registres correspondants à analyser. Mais je vois pas l'intérêt si on s'assure que de chaque coté, les données n'arrivent pas trop vite et que leur traitement par la cpu se passe correctement, y en a pas d'erreur. De toute façon, s'il y a des erreurs, c'est mort, le programme receveur ne pourra rien faire à part redemander le fichier ou un de ces morceaux. C'est pourquoi on ajoute au fichier des octets checksum, pour s'assurer de l'intégrité des données transférées.

Le RTS/CTS c'était avant car les ordinateurs étaient poussifs, on contrôlait le flux, en hard RTS/RTS, ou en soft Xon/Xoff. Tu peux les utiliser pour mettre en stand-by le transfert, Tera Term devrait gérer ça. Je pense que ce serait quand même plus sur de faire ses propres softs, un côté PC, l'autre côté pic, pour insérer des messages en cours de transfert, on instaure un dialogue supervisant le transfert. Pas de problème, je te fais ça pour demain matin :)
Mise à part les parasites en milieu pollué, la liaison série ça tourne bien et vite, si les 2 horloges sont synchro.
C'est mon expérience, chacun son avis.

Soft de commande CNC en asm
F6FCO
Avatar de l’utilisateur
Expert
Expert
Messages : 1413
Âge : 70
Enregistré en : décembre 2017
Localisation : Furtif je suis.
Contact :

#54 Message par F6FCO » sam. 5 mai 2018 11:11

Bonjour un peu moins matinal,

Cette conversation est très intéressante, pour moi en tout cas parce que je découvre un nouveau domaine :wink: .
Pour commencer clair, voilà le style de gcode simplifié que j'utiliserai, pas de pbm je sais le générer facilement:

M18.JPG


Dans l'idéal voilà ce que j'aimerai pouvoir faire:
Les lettres d'axes X,Y,Z codées sur 1 octet (ascii), les valeurs codées sur 2 octets, donc 3 octets par ligne.
Le PIC serait maitre et le PC esclave.
Le PC attends les ordres du PIC pour envoyer des salves de 3 octets (pour 1 axe ou 9 octets si on traite les 3 axes par salve).

- Le PC envoie 1 paquet
- le PIC lui dit "STOP", il traite l'info et gère le mouvement de l'axe en question.
- Une fois fini il donne l'autorisation au PC d'envoyer la salve suivante.
- Le PC envoie 1 paquet suivant
- etc. etc.

Possible de faire çà ?
Je suis en pleine recherche mais dans tout ce que je trouve sur le net concernant les liaisons PIC/PC en RS232, le PC et toujours maitre et attends des infos venant du PIC. En plus il n'y a que RX/TX d'utilisés, donc pas simple :roll:
Je viens de commander des MAX232 et des prises DB9, faut attendre que çà arrive de Chine.
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Une porte nand prend 2 bits en entrée... la cochonne !!! :langue:

Soft de commande CNC en asm
satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

#55 Message par satinas » sam. 5 mai 2018 13:41

Pour la Chine, les délais s'améliorent, j'ai reçu des trucs en 5 jours.
Achète un lcd spi, on fera défiler les commandes dessus (je dis surtout ça parce que y a un lecteur SD intégré :) 1200 mots programme pour la sd)
Pourquoi veux-tu ajouter un fil ? A à partir du moment où il y a dialogue avec des règles établies, les 2 parties s'y conforment et on fait ce qu'on veut, commandes, données. A 9600 bauds, un octet arrive en 1ms. Le Pic temps réel réagit sur l'instant, le PC on sait pas trop, mais je suppose que ces timings ne sont pas critiques dans ton appli.
La programmation côté PC ou pic est similaire. Pour le PC, ce sera simple car il ne fait que lire un fichier et l'envoyer par morceaux numérotés et checksumisés. L'appli côté pic c'est là qu'il y a du boulot on dirait.
les échanges se font sous-forme de trames de type entête+numéro+datas+checksum, avec acquittement immédiat, et renvoi si non acquittement ou time-out. Les trames sont numérotées pour éviter d'exécuter 2 fois la même commande, ou s'il en manque une la machine s'arrête.
Combien de temps la machine peut patienter si une commande met du temps à arriver ?

Soft de commande CNC en asm
F6FCO
Avatar de l’utilisateur
Expert
Expert
Messages : 1413
Âge : 70
Enregistré en : décembre 2017
Localisation : Furtif je suis.
Contact :

#56 Message par F6FCO » sam. 5 mai 2018 15:42

Je vais répondre en citant ton discours ce sera plus simple pour avoir une discussion claire car tu maitrises ton sujet mais moi pas du tout :wink: .
satinas a écrit :Achète un lcd spi, on fera défiler les commandes dessus (je dis surtout ça parce que y a un lecteur SD intégré :) 1200 mots programme pour la sd)
?

Tu as un lien ? j''en ai vu mais qu'on parle bien de la même chose.

satinas a écrit :Combien de temps la machine peut patienter si une commande met du temps à arriver ?

A partir du moment ou une commande (un paquet de 3 octets) est arrivée du PC sur le PIC, le pic doit traiter l'info avec son interpréteur de gcode, puis faire bouger l'axe en question, opération longue qui peut prendre quelques secondes.

satinas a écrit :Pourquoi veux-tu ajouter un fil ?

J'imagine qu'il faut que le PIC puisse donner l'ordre au PC d'envoyer ou attendre pour émettre les paquets, je pensais pour cela utiliser les connections RTS et CTS.

satinas a écrit : mais je suppose que ces timings ne sont pas critiques dans ton appli.

Je suppose que non

satinas a écrit :les échanges se font sous-forme de trames de type entête+numéro+datas+checksum, avec acquittement immédiat, et renvoi si non acquittement ou time-out. Les trames sont numérotées pour éviter d'exécuter 2 fois la même commande, ou s'il en manque une la machine s'arrête.

On a une conversation un peu décousue parce que je connais rien au sujet. Pour qu'on parle de la même chose tu aurais des liens que je puisse consulter ?
Dans mon esprit le PC envoie la totalité du gcode en une seule fois, mais le PIC est incapable de stocker ce programme pour cause de mem trop étriquée, d'ou l'idée d'envoyer le programme par morceaux qui seraient traités au fur et à mesure.
Une porte nand prend 2 bits en entrée... la cochonne !!! :langue:

Soft de commande CNC en asm
satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

#57 Message par satinas » sam. 5 mai 2018 16:34

Une communication asynchrone série c'est 2 fils et une masse :
- le fil TX du pic qui va vers le RX du PC, sur lequel transitent des octets dont les bits sont à la queue-leu-leu
- le fil TX du PC qui va vers le RX du pic, idem

Les 2 peuvent envoyer des octets à tout moment sur leur TX et ça arrive de l'autre côté.
Le pic peut envoyer autant d'octets, des commandes dans ton cas, qu'il veut au PC sur son fil TX, pourquoi veux-tu mettre un fil supplémentaire pour faire la même chose ?

- le pic envoie sur son TX l'octet 0x06 au PC (0x06 = commande "envoie-moi un paquet")

- le PC recoit la commande sur son RX et aussitôt envoie sur son TX un paquet de 6 octets 0xAA 0x01 0x58 0x37 0x38 0x67
0xAA entête, suivi du numéro de ligne gcode 1, suivi de la ligne gcode en ascii "X78" suivi du checksum 0x67 calculé sur les 5 premiers octets

- le pic reçoit les 6 octets sur son RX, calcule le checksum des 5 premiers octets, vérifie qu'il est conforme au 6ème octet
Si c'est bon il exécute la ligne gcode puis envoie sur son TX l'octet 0x06 (acknoledge)
Si le checksum n'est pas le même, il envoie sur TX l'octet 0x15 (non acknoledge)

- si le PC reçoit sur son RX un 0x06, il envoie la ligne gcode suivante dans un nouveau paquet
- si le PC reçoit sur son RX un 0x15, il renvoie le paquet qu'il vient d'envoyer

et ainsi de suite ...

La question était : la machine peut-elle supporter que des commandes ne lui soit pas envoyées pendant quelques secondes.
Je connais pas ces machine CNC, imprimante 3D ... Est-ce qu'on peut faire une pause en cours de fabrication d'une pièce, et reprendre ensuite le gcode. Au cas où il y aurais un sérieux problème de communication avec plein de "non acknoledge".

https://www.ebay.fr/itm/240x320-2-4-SPI ... SwfrxZy0hp
Modifié en dernier par satinas le sam. 5 mai 2018 21:20, modifié 1 fois.

Soft de commande CNC en asm
satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

#58 Message par satinas » sam. 5 mai 2018 18:28


Soft de commande CNC en asm
F6FCO
Avatar de l’utilisateur
Expert
Expert
Messages : 1413
Âge : 70
Enregistré en : décembre 2017
Localisation : Furtif je suis.
Contact :

#59 Message par F6FCO » sam. 5 mai 2018 20:04

Merci c'est beaucoup plus clair maintenant :wink:
Quelques questions néanmoins pour affiner:

satinas a écrit :Le pic peut envoyer autant d'octets, des commandes dans ton cas, qu'il veut au PC sur son fil TX, pourquoi veux-tu mettre un fil supplémentaire pour faire la même chose ?

Effectivement, je voyais plus compliqué.


satinas a écrit :Une communication asynchrone série c'est 2 fils et une masse :
- le fil TX du pic qui va vers le RX du PC, sur lequel transitent des octets dont les bits sont à la queue-leu-leu
- le fil TX du PC qui va vers le RX du pic, idem
Les 2 peuvent envoyer des octets à tout moment sur leur TX et ça arrive de l'autre côté.
- le pic envoie sur son TX l'octet 0x06 au PC (0x06 = commande "envoie-moi un paquet")

La valeur 0x06 c'est le nombre d'octets demandés ? si on envoie 0x09 il y aura un paquet de 9 octets ? ou bien c'est une commande formatée qui veut juste dire envoie moi un paquet ?

satinas a écrit :- le PC recoit la commande sur son RX et aussitôt envoie sur son TX un paquet de 6 octets 0xAA 0x01 0x58 0x37 0x38 0x67
0xAA entête, suivi du numéro de ligne gcode 1, suivi de la ligne gcode en ascii "X78" suivi du checksum 0x67 calculé sur les 5 premiers octets

Le checksum c'est bien la somme des octets précédents en binaire avec complément à 2 ? je ne trouve pas la même valeur. Pas pour chercher la petite bête hein! mais pour comprendre, je serai obligé de gérer çà pour répondre au PC.

satinas a écrit :- le pic reçoit les 6 octets sur son RX, calcule le checksum des 5 premiers octets, vérifie qu'il est conforme au 6ème octet
Si c'est bon il exécute la ligne gcode puis envoie sur son TX l'octet 0x06 (acknoledge)
Si le checksum n'est pas le même, il envoie sur TX l'octet 0x15 (non acknoledge)

- si le PC reçoit sur son RX un 0x06, il envoie la ligne gcode suivante dans un nouveau paquet
- si le PC reçoit sur son RX un 0x15, il renvoie le paquet qu'il vient d'envoyer

0x06 acknoledge, rien à voir je suppose avec la première commande qui a la même valeur ?

satinas a écrit :La question était : la machine peut-elle supporter que des commandes ne lui soit pas envoyées pendant quelques secondes.
Je connais pas ces machine CNC, imprimante 3D ... Est-ce qu'on peut faire une pause en cours de fabrication d'une pièce, et reprendre ensuite le gcode. Au cas où il y aurais un sérieux problème de communication avec plein de "non acknoledge".

Oui tout a fait, elle peut attendre. C'est le PIC qui la commande et c'est moi qui fait le programme :-D. Le PIC traite le gcode, fait bouger le moteurs d'axe concerné et seulement après redemandera un nouveau paquet. Si le paquet n'est pas dispo on attends qu'il arrive en ne faisant rien.



En 3.3v, je vais essayer de trouver le même en 5vcc. Mais un truc me chipote, on parle bien de RS232 et cet écran est en SPI, donc pas le même protocole et pas les même liaisons.
Une porte nand prend 2 bits en entrée... la cochonne !!! :langue:

Soft de commande CNC en asm
satinas
Expert
Expert
Messages : 1225
Enregistré en : novembre 2015

#60 Message par satinas » sam. 5 mai 2018 21:19

Même si les instructions gcode sont de taille variable, il vaut mieux ajuster les paquets à une taille fixe pour simplifier la vie du pic. Il attend des paquets de taille fixe, si un octet se perd, il le comprend tout de suite et envoie aussitôt 0x15

0x06 et 0x15 c'est ACK et NAK. On leur donne la valeur qu'on veut puisqu'on fait les programmes des 2 côtés. Le checksum pareil, on le calcule comme on veut. J'ai choisi les valeurs historiques pour ACK et NAK, voir la table ascii dans la vidéo à 3:00

Le programme PC est tout simple.
Son pointeur de ligne gcode démarre à -1, et il attend
- réception ACK
il incrémente le pointeur ligne de code
il envoie le paquet la contenant
il garde en mémoire le paquet envoyé
- réception NACK
il envoie le paquet en mémoire
- autre réception
il fait rien

si un ACK ou un NAK se perd, le pic le réitère, ne voyant rien arriver. C'est le pic qui réfléchit, le PC pas du tout. Le premier ACK est particulier puisqu'il n'acquitte rien, mais pour le PC il n'y a pas de différence. Pour les détails on verra plus tard, je pense que tu as compris le principe.

Pour l'écran, je pense qu'il est compatible 5V, il a un régulateur sur les images. Par contre je me suis planté, il a pas le chip contrôleur tactile installé, voir images. J'avais prévenu sur un autre post, et là je suis tombé dedans :)
Celui-ci a bien le contrôleur tactile, mais il est plus cher
https://www.ebay.fr/itm/240x320-2-4-SPI ... SwfrxZy0hp
Avant il y avait des lcd sans tactile, mais ils ont disparu, il y en a dans des plus petite tailles.


Retourner vers « Langage ASM »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 38 invités