dsDRO

[Fred8]

-Affichage sur un terminal série
-Affichage sur un programme dédié (dans loooongtemps :p )
-Affichage sur un écran LCD 4*20 (cela viendra rapidement si les bibliothèques de C30 possèdent les 'drivers' pour)

et bien sur un bootloader pour upgrader si y'a une nouvelle fonction qui est apparue entre temps

Donc je commence à coder...
Si il y a des personne qui veulent participer, vous êtes les bienvenues
Max

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?

 

[MaX-MoD]

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é.

 

[Sanson]

l'optocouplage de RX et TX c'est la facilité.

C'est surtout, jouer la sécurité.

L'idéal étant d'avoir une masse commune entre tous les appareils

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.

 

[erolhc]

l...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

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)

 

[MaX-MoD]

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.

 

[wika58]

...
-4 entrées PAC
-1 entrées encodeur avec broche d'index
-un afficheur LCD
-une liaison RS232

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é.

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)?

 

[erolhc]

@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)

 

[MaX-MoD]

@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

 

[wika58]

@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.

..

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...

 

[MaX-MoD]

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:

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.

 

[bebert2611]

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.) ?

 

[wika58]

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.

 

[wika58]

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,...

 

[bebert2611]

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.

 

[wika58]

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 ...

 

[MaX-MoD]

J'ai fait une ébauche (la mise en page est caca, mais l'essentiel du principe y est) du protocole.

dsDRO: communication série


début d'une 'trame' de coordonnées: caractère '#'
une lettre précède une position: X, Y, Z, A, B, C etc.
les coordonnées sont affichées en 'clair', le formattage se faisant pas dsDRO
le caractère '_' marque la fin d'une trame, et dont le rafraîchissement de l'affichage PC.
les unités sont transmises par un code, et précédées de la lettre 'U'
La vitesse de la broche est précédée par 'V'

ex:

#X20.21Y10.70Z-157.3U3V3600.1_

<=> X=20.21
Y = 10.70
Z = -157.3
Vitesse de la broche 3600.1
unités de longueur: mm
rotation indiquée en °



le code des unités est calculé comme suit:
si dimensions en mm, on ajoute 1, si en pouce, 0

si angles en °, on ajoute 2, si c'est en impulsion encodeur, on ajoute 0




##Paramètres COM:
8bit, pas de parité, 1 bit de stop, 9600pbs, pas de contrôle matériel du flux


##Envoi de commandes:
Envoyer la chaine de caractères "M1\r\n" revien à exécuter la commande M avec pour paramètre 1.

##Entrée en mode d'affichage continu:
envoyer la commande <<M1>>.
dsDRO envoie alors une chaine du type <<#X20.21Y10.70Z-157.3U3V3600.1_>> à intervalles variable.
tout envoi d'un caractère (alphanumérique, \r, \n etc.), arrête la diffusion inintérompue.

##Configuration:
La configuration se fait par terminal série (à l'image de Hyperterminal), qui pourra être intégré à la partie PC.
la partie PC ne s'occupe que de l'affichage des chaines de caractères et de la transmission des entrées clavier.
L'écho des touches frappées est assuré par dsDRO.

L'idéal est donc que la console soit réservée au paramétage; il faudra disposer d'une option visant à intercepter les paquets commencant par un '#' et finissant pas un '_'
Les caractèes '#' et '_' ne sont transmis que pour l'affichage continu des coordonnées.
Ils ne devront pas non plus être envoyés à dsDRO.

UNE SEULE EXCEPTION: la commande 'U', pour le paramétrage des unités.
envoyer "U3\r\n" revient à paramétrer dsDRO pour convertir les unités en mm et °.
il faudra envoyer de nouveau la commande <<M1>> pour reprendre l'affichage en continu.

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

 

[Fred8]

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.

 

[MaX-MoD]

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

 

[MaX-MoD]

alors, ça avance ce LCD?

sinon y'a ça: http://www.erturkonline.com/content/vie ... 1/lang,en/
direct sur C30...

De mon coté ça n'avance pas.
Trop de boulot (et surtout pas la motiv de torcher ça vite fait), pas le temps de continuer.

Mercredi je devrais pouvoir me pencher plus dessus.

 

[Fred8]

alors, ça avance ce LCD?

sinon y'a ça: http://www.erturkonline.com/content/vie ... 1/lang,en/
direct sur C30...

De mon coté ça n'avance pas.
Trop de boulot (et surtout pas la motiv de torcher ça vite fait), pas le temps de continuer.

Mercredi je devrais pouvoir me pencher plus dessus.

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.

 

[MaX-MoD]

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 !

Super!

mais où est le zip?

Allé Max, +5% sur le dsDRO.

C'est fait

 

[Fred8]

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 mesures Voir la pièce jointe LCD 4x20.zip Et le driver pour Max Mod ! Attention, driver pour KS0066U et équivalents.
T'as intérêt à assurer mercredi mon gars !

 

[MaX-MoD]

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

 

[Fred8]

Alors? Pas de nouvelles...te connaissant, tu n'as pas eu le temps d'y travailler

 

[MaX-MoD]

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!

 

[MaX-MoD]

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érie Voir la pièce jointe dsDRO.zip Et le projet zippé

 

[wika58]

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...

 

[MaX-MoD]

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 )

 

[Fred8]

De quoi tester les messages sur le LCD sans s'embêter à flasher le PIC : Voir la pièce jointe Test rendu écran LCD 4x20.zip

 

[MaX-MoD]

De quoi tester les messages sur le LCD sans s'embêter à flasher le PIC :

truc de geek
il manque plus qu'une police "5x7" et l'immersion est totale^^

sinon, ça en est où coté PC Wika?
J'ai rapidement jeté un coup d'oeuil à QDevelop avec Qt4, ça à l'air assez simple.
y'a aussi une lib port série multiplateforme : http://qextserialport.sourceforge.net/

voila.
A+

Max