dsDRO

  • Auteur de la discussion Auteur de la discussion MaX-MoD
  • Date de début Date de début

Je résume un peu :

- Affichage sur un terminal série : TX et RX du module maître dsDRO doivent être optocouplés. Sortie sur un protocole type RS232 mais en 0-5V. Exploitation par un module à MAX232 ou FTDI (le FT232RL pour moi),
J'ai de quoi tester la solution FTDI. Qui s'occupe de ce routage? Max? Psykok?

- Affichage sur un programme dédié : je crois que Wika peut se débrouiller avec un copain, et Coredump peut aussi aider.

- Affichage sur un écran LCD 4x20 : je suis en train d'y travailler (75% de fait, les 25% restants pour les essais!). Dès que çà marche, je peux fournir la bibliothèque en C (ce n'est pas du C30, MAX, désolé !, compilé avec PIC C CCS, je n'ai utilisé que des fonctions bâteau). Je me propose pour la réalisation de cette partie, routage+programmation. J'utiliserai un PIC 16 ou un PIC18, genre 16F873 par exemple, ou 18F4xxx.

- Bootloader : Max?

- Carte dsDRO : qui s'en occupe? Max? Psyckok?
 
l'optocouplage de RX et TX c'est la facilité.
L'idéal étant d'avoir une masse commune entre tous les appareils reliée à la terre, je me demandes ce que ça peut donner (et terme de sensibilité aus parasites etc.)
mais vu que ça fonctionne déjà comme cela, on fera de cette manière, et on verra par la suite si l'utilisation d'une masse commune comme il faut change quelque chose ou non.


sinon je crois que tu as bien résumé.
Je vais m'occuper du routage de la carte principale, car il me faudrais de toute façon produire le schéma.

C'est bien que tu aies fait une bib pour le LCD!
Vu que c'est toujours du C, ce ne devrait pas être trop dur à adapter vers C30!
Et en y repensant, il ne faut normalement que 6 E/S pour piloter un 4*20: 4 de données, 2 de contrôle. (cf datasheet, l'entrée R/W étant mise à la 'masse')
sur un 30F4012 en 28 pattes, on peut alors utiliser simultanément:
-4 entrées PAC
-1 entrées encodeur avec broche d'index
-un afficheur LCD
-une liaison RS232

J'avais oublié que les LCD pouvaient prendre 8 bits d'un coup ou deux fois 4, réduisant donc le nombre de sorties nécessaires de 10 à 6...

Il n'y a donc plus besoin de faire un module LCD, seulement un module LCD pour ceux que ça intéresse.
à moins que vous ayez plus de 4 PAC sur votre machine?!? mais dans ce cas le 30F4011 vous permettra d'en avoir une ptite dixaine

Quant au bootloader, de nouveau je penche sur celui d'Ingenia, qui est d'après mes tests sur YAPSC complètement fonctionnel.
Il parait qu'il y a une version Java du bootloader sous nunux/mac...
Mais de toute façon la communication entre PC et PIC est facile à reproduire, créer une version stable pour nux/mac etc. sera pas trop compliqué.
 
MaX-MoD a dit:
l'optocouplage de RX et TX c'est la facilité.
Cliquez pour agrandir...
C'est surtout, jouer la sécurité.
MaX-MoD a dit:
L'idéal étant d'avoir une masse commune entre tous les appareils
Cliquez pour agrandir...
Ce devrait être le leitmotiv !

Déjà qu'en temps normal, même bien étudié, les parasites nous pourrissent la vie ...., sur une machine à bonne tension et à bonne intensité, pourvue de nombreux bobinages générateurs de parasites, il vaut mieux mettre tout de son coté, c'est à dire : ligne de masse câblée "en étoile" de rigueur.

Sur les câbles "petits signaux", des condensateurs de découplage ne seraient pas les mal venu .....
Liaisons à la masse des blindage ... en un seul point, reprises de masse , .... etc.
 
Il existe des LCD série aussi cela à l'avantage de rendre votre montage indifféremment compatible soit avec le pc soit avec le LCD : il suffit d'adopter le même protocole de communication pour les deux (commandes et données) . Cela simplifie la programmation du pic et ne complique pas celle du pc (il faudra bien définir comment interpréter ce que le pic envoi au PC) puisque c'est la même. De même pour l'électronique. L'utilisateur final n'a qu'a choisir de brancher le montage soit au pc soit à l'afficheur tel que (alim 5V a fournir ?).
Seul inconvénient un afficheur série vaut environ le double d'un parallèle. Ou alors vous faites un module LCD série avec un afficheur LCD parallele mais avec un petit pic qui interpretera les commandes du pic principal mais bon la ca commence à compliquer et cela revient à inverser la solution de départ (double programmation (pc - pic)
 
question parasites, j'avais lu la presque entièreté d'un document d'une soixantaine de pages sur le blindage, dessin des pistes, câblage des masses etc.
Eh bien ma fois c'était très instructif.
Il y avait des comparaisons entre plusieurs routages du même circuit et les résultats obtenus, la différence était flagrante!
mais évidemment ça fait partie des trucs que j'ai perdu dans le (plutôt un des) crash de windaube

mais il y a aussi de nombreux documents là dessus, ici par exemple: http://www.tech-diy.com/smps.htm


Sinon bonne remarque Chlore, mais personnellement j'ai écarté l'idée d'utiliser un module LCD série tout fait, car il y en a quantité et qui utilisent à chaque fois un protocole différent, dans la plupart des cas incompatible avec une liaison RS232 ASCII
Et puis vu qu'on a déjà une bib grace à Fred8 et les ports disponibles, pourquoi se compliquer la vie?
En plus l'utilisateur a un choix bien plus vaste d'écran, le HD7machin est un grand classique.
 
MaX-MoD a dit:
...
-4 entrées PAC
-1 entrées encodeur avec broche d'index
-un afficheur LCD
-une liaison RS232
Cliquez pour agrandir...
Et l'entrée vitesse broche c'est l'entrée encodeur dont tu parles...

...IMais de toute façon la communication entre PC et PIC est facile à reproduire, créer une version stable pour nux/mac etc. sera pas trop compliqué.
Cliquez pour agrandir...
J'en ai parlé à mon copain qui est informaticien (Linux). Il est d'accord.

Il faudrait définir un protocole d'échange...
Tu avais déjà brièvement abordé le sujet...
Comment vois-tu les choses: une trame ASCII, une chaine de valeurs,...
A quelle vitesse la transmission (19200)?
 
@Max-Mod

Quand je parlais serie je pensais évidement à RS232C (pas 422, IC2, etc ..) hormis signal en 5V pas en 12V.
Par protocole j’entendais par la comment le pc va interpréter ce que va envoyer le pic c'est-à-dire sous quelle forme.
Avec un LCD //. Tu dois avoir une façon de dialoguer avec l’afficheur et une autre façon pour le pc (par exemple pour dire que ce que tu envois est le déplacement sur les X) . Alors qu’avec un LCD série que n’a besoin que d’une seule façon (mot de commande comme quoi tu écrits puis les coordonnées ou tu veux que cela commence sur l’afficheur et ensuite ta série de chiffre puis un mot de fin. Avec un PC il suffisait de lui apprendre ce protocole (celui la ou un autre …) et au niveau programmation du pic c’etait simplifié (un seul code sans se soucier si c’est un LCD ou un PC derrière sur les broches TX/RX (avant ou après le Maxx suivant le cas puisque normalement un LCD série est connectable directement sur le PIC. Par contre la ou tu as raison le protocole des données peut être (ou pas ?) différent suivant la marque du LCD donc ça peut poser effectivement problèmes pour un système pouvant être construit par de multiples personnes et donc sources d’appro différentes. Et puis en fait un LCD série et plus de 3 fois plus cher qu’un parallèle (du moins en france)
 
@Wika:

J'ai en effet oublié cette entrée vitesse de broche
l'entrée encodeur c'est pour un 4e axe.

ceci dit, on peut utiliser une des entrées PAC ou l'entrée INDEX de l'encodeur comme entrée vitesse de broche, on contenterait alors toujours 90% des utilisateurs de dsDRO avec 4 axes et vitesse de broche.
et pour ceux qui en veulent plus, ils pourront utiliser un 30F4011.


@Chlore:

L'utilisation d'un protocole commun (je bien compris ce que tu voulais dire ) à LCD et PC est une bonne idée en soi, mais ça aurait tout compliqué: dsDRO, et l'appli PC.
La communication texte via série entre un PIC 16b et un PC est d'une simplicité crasse: la partie software se résume à printf("Hello World!\r\n"); le PC récupère directement une chaine de caractère lisible en clair.
Mais il n'en est généralement pas de même avec les LCD série, et quitte à devoir développer un 'driver' LCD, autant le faire pour un LCD // puisqu'on a les ports dispo pour ça.
la surcharge de travail n'est pas excessive et au final la flexibilité s'en voit grandement améliorée.

A+
Max
 

Tu sais, il y a un PAC et un encodeur pour le 4° axe.
En général le 4° axe est justement un axe de rotation...(encodeur)
Donc utiliser l'entrée PAC n°4 pour la vitesse broche je crois que c'est OK pour tous.
Si on a les 3 axes en PAC + le 4° en encodeur et la vitesse broche c'est déjà super comme DRO...
 
c'est ce que je me disais...

Sinon j'ai oublié une une ou deux réponses...
La vitesse série est pour l'instant de 57600bps, le transfert des coordonnées au programme dédié serait de la forme AxxxxxBxxxxxxCxxxxxx_ chaque lettre représente un axe, xxxxx la valeur et _ est un caractère de synchro etc.
à l'origine, je pensais utiliser hyperterm ou tout équivalent et transférer le tout déjà formaté, de ce genre:
Code:
Vous devez être connecté pour voir ce contenu.
je testerais à l'occas si on peut avoir un 'flash' entre deux rafraîchissements, car mon idées c'était d'utiliser une vitesse de com très haute pour pouvoir utiliser un simple terminal, sans avoir besoin de faire un prog PC...

voila.
 
Bonsoir,

J'avais 4 questions d'huitre, et si ça pollue le fil, vous me dites :

1) je ne comprends pas pourquoi vous utilisez des encodeurs, comme capteurs, s'il y a des PAC qui mesurent les déplacements.
carte-servos-a-dspic-t648.html

Les encodeurs ont peut-être une meilleure résolution, mais n'y a-t-il pas une perte de précision, avec le jeu de la transmission ?

2) il faut combien de Mips pour gérer un paquet de PAC ?
30Mips pour 4 PAC (avec un 30F4012), 30Mips pour 10 PAC (avec un 30F4011) .... on pourrait aller jusqu'à combien de PAC, avec un 30F5015, par ex. (30 Mips, 52 I/O pour ce PIC) ?

3) Il y a 6 à 8 PMW sur ces PICs. En mettant un étage PID, entre le capteur et le PMW, quelque est la consomation en Mips, par moteur asservi ?

4) du point de vue pratique, ça pose pas de pb, la mise en oeuvre de ces dsPIC (écartement des pattes, par ex.) ?
 
OK pour le protocole de Com avec le PC.
Le formatage de données que tu proposes est très bien et super simple.
Au niveau de la vitesse de com, j'espère que mon vieux portable monte jusque là (Pentium I - HP Omnibook 6000)...

C'est vrai qu'il serait possible de simplement utiliser un émulateur de terminal sous Windows ou sous Linux.
On pourrait même utiliser un vieux terminal des années 80 style VT220, VT340,...
Le problème si tu veux utiliser un terminal c'est que tu dois transmettre aussi les informations de mise en page, les unités,...
Si on fait une petite appli en soft, il ne faut que transmettre les valeurs...

Moi je voudrais un joli affichage avec de GRANDS caractères pour ma vue qui baisse...

Je vois avec mon copain pour faire un exemple et je le posterai.
 
Bebert,

Les PAC c'est pour les déplacements linéaires X, Y, Z et l'encodeur c'est pour l'axe de rotation A,...
 
Sur l'autre fil
carte-servos-a-dspic-t648.html
il n'est question que d'encodeurs...d'où ma question d'huitre.

Ça sort un peu du fil DRO, mais comme on doit pouvoir gérer un assevissement, en plus d'une DRO, je me posais la question.
 
Il n'a y pas d'huitres ou pas...
C'est le principe de ce forum,...
...on pose la question et quelqu'un qui sait répond...
N'est-ce pas super ...
 
J'ai fait une ébauche (la mise en page est caca, mais l'essentiel du principe y est) du protocole.

l'utilisation d'un terminal est bien sûr par soucis de simplicité: pas besoin d'appli ni même de protocole compliqué, tout se fait en clair.

j'ai pas précisé, mais 57600 c'est pour l'affichage continu sur un terminal.
9600bps, est bien plus adapté pour le protocole que je décris.
ça permet le rafraîchissement à 60Hz de plus de 10PAC.

quant aux nombre de PAC maximal, ça dépend.
il peut y avoir perte ou corruption d'un paquet su plusieurs règles décident d'envoyer toutes en même temps.
mais mon pifomètre me dit que même avec une dixaine de PC ça reste exploitable.
c'est pas vraiment le nbr de MIPS mais la latence et la gestion des interruptions qui qui est importante.

Quant à l'asservissement d'un moteur, c'est intéressant comme idée
Vu que ce n'est pas de la CN, on peut se permettre de faire des boucles PID assez lentes (<1KHz) sans trop de problèmes.
à voir pour la suite.

et pour réponse à la dernière question d'huitre non, aucun problèmes, les 30F4012 et 30F4011 sont en boitier DIP écartement 2.54mm.
c'est aussi une des raisons de leur sélection
 
Peut-être prévoir des caractères de sécurité pour le début et la fin de la trame, caractères qui ne seront pas compris si un des bits saute à cause du bruit. J'utilise toujours 0xAA et 0x55, ce qiu correspond en binaire à b'10101010' et b'01010101'.

Pour le pilote LCD, et zut, il est en 8 bits de données...j'avais commencé par le 4 bits et je me suis dit que c'était pas top pour le raffraichissement de 6*4 = 24 digits.
Bon, je vais le terminer en 8 bits, et j'incluerai le même en 4 par la suite. La fonction sera accessible au choix via un #define.
Si tout va bien ,çà devrait tourner ce WE.
 
Ok, on testera ça ce WE

par contre il y aura une pause entre chaque trames
Donc pas besoin de caractères de sécurité.
D'autant plus que les données ne sont pas vraiment critiques

Bonne soirée
Max
 

Ouaip, çà marche ! En 4 bits (uniquement, le 8 bits n'est pas du tout au point). Je ne suis pas parti de ton lien, mais ma fonction y ressemble trait pour trait. Comme quoi, les solutions tournent !

Allé Max, +5% sur le dsDRO.
 
Fred8 a dit:
Ouaip, çà marche ! En 4 bits (uniquement, le 8 bits n'est pas du tout au point). Je ne suis pas parti de ton lien, mais ma fonction y ressemble trait pour trait. Comme quoi, les solutions tournent !
Cliquez pour agrandir...
Super!

mais où est le zip?


Fred8 a dit:
Allé Max, +5% sur le dsDRO.
Cliquez pour agrandir...
C'est fait
 
Un petit aperçu (petit, car c'est une petit écran, caractère de 4.85mm).
Le contraste est excellent, mais il est mal rendu par les photos.
Angles de vision pour un contraste excellent : +/- 45° en horizontal, +20/-50° en vertical.

Le splascreen (désolé, le &quot;s&quot; a ripé en &quot;r&quot; !)

Les mesuresVoir la pièce jointe LCD 4x20.zipEt le driver pour Max Mod ! Attention, driver pour KS0066U et équivalents.
T'as intérêt à assurer mercredi mon gars !
 
pas mal

allez 4/5, y'a une faute de frappe

Cela dit, j'arriverais pas à faire les 80% restants d'ici à mercredi

A+
Max
 
Alors? Pas de nouvelles...te connaissant, tu n'as pas eu le temps d'y travailler
 
Faut déjà que je remontes ma planche à pain, etc. etc.

mais je devrais pouvoir y consacrer une partie de mon aprem, après CV lettres de motiv et tout le bronx!
 
Bip Bip!

Voila, ça commence à resssembler à quelque chose, et à être utile: ça affiche la valeur de l'entrée encodeur
Reste les menus, config, etc. etc.

bricolage bricolage...

sur la console sérieVoir la pièce jointe dsDRO.zipEt le projet zippé
 
Une question que je me pose depuis quelques temps.
Comment prévois-tu la remise à zéro de la mesure lors de la prise de références.
Est-ce que c'est sur le PAC que le zéro est fait ou bien est-ce que c'est au niveau du PC que le zéro est fait?
Et dans ce cas, est ce le PC qui envoie un code au dsDRO qui lui pilote le bouton RAZ de PC ou bien le PC fait un offset sur les mesures que lui envoie le PAC...
Merci...
 
dsDRO utilisera la pos "absolue" ou "affichée sur l'écran du PAC" au choix (menu)

avec logiciel dédié, dsDRO envoie la même chose sur logiciel dédié et console série.
la fonction 'O' permet de régler les offset:

"O0" met à 0 tous les offset
"OX12.5" met l'offset des X à +12.5mm
"OX-12.5" @ -12.5mm
"O1" envoie un seul paquet formé comme les paquets de position, mais avec uniquement les offset à la place des positions. les paquets suivants sont normaux, ils contiennent donc les positions des axes.

pour l'entrée encodeur (axe A) en mode rotation:
"OA45d" correspond à un offset de +45°
"OA152" correspond à un offset de 152 IMPULSIONS (+ précis, pas de pertes par conversion °->impulsions)



va falloir mieux documenter tout ça...

Ah, et j'ai intégré un support multi langues: tous les messages se trouvent dans un seul .h, ce sera donc facile de supporter plusieures langues.
Il faut par contre télécharger un nouveau binaire dans le PIC pour changer de langue (faut pas déconner non plus )
 
Pour répondre, connectez ou inscrivez vous.

Sujets similaires

QCAD - Souci de texte qui se déplace tout seul
Réponses
2
Affichages
249
crapulatos
G
CNC Profilé Alu 80160
Réponses
23
Affichages
1 125
mpvue91
M
M
Projet Plieuse sur presse, à partir de machoires
Réponses
14
Affichages
1 458
Mic736
M
Conception et réalisation d'un panneau de contrôle CN
2
Réponses
41
Affichages
2 234
ncx94
Dépannage Règles Heidenhain cassées, que faire....?
Réponses
4
Affichages
1 489
Hubert95
H
S
linuxcnc carte mesa 6i25 + 7i75 +7i78 + jog mpg chinois
Réponses
0
Affichages
824
serrepattes
S
J
Modification BF20L - Changement moteur & Électronique
Réponses
21
Affichages
601
ramses76
Projet Choix tour monophasé, OPTIMUM ou HBM ?
Réponses
15
Affichages
5 311
fauxjetons
VISU SINO - Longueur règle
Réponses
20
Affichages
759
yves 26
A
Entrées / Sorties / Retrait, type etc... MASTERCAM (2024)
Réponses
1
Affichages
285
AquaPulco
A
CNC shield vs MKS DLC32
2
Réponses
54
Affichages
4 244
pascalp
P
P
Impression de court circuit sur TB6600
Réponses
1
Affichages
244
PepeMax
P
L
Résolu CELTIC 12 - Boîte bloquée en pas de 0.75
Réponses
25
Affichages
2 271
bricoleur13
B
E
Mise en route à blanc CN8055 et MON55TC11LCD
Réponses
3
Affichages
489
mickbzh
B
Dépannage CHOLET 550 - Démontage boîte de vitesse
Réponses
3
Affichages
3 711
Quentin1377

Sujets similaires

dsdro et carte de laison pour regle
Réponses
0
Affichages
2 205
david 007
Menu
Connexion
S'inscrire