Programmation d'un modbus RTU

Bonjour,

Voila je me met enfin sur l'embarqué et avec du lourd puisque c'est la création d'un modbus en RTU.
Donc gestion de timer.

Avez vous quelques bricoles qui pourrais me lancé sur la façons de gérer cela, genre un diagramme UML ou autre, me permettant de m'engager sur quelque chose de bien construit.

La partie réception des données, crc, est déjà effectué, le mode ASCII étant déjà implémenté. C'est juste la partie timer que je dois implémenter, et la façon de gérer cela.

On travail avec un PIC24HJ256GP610.

j'ai réussi a faire quelques bricole avec les timer, afin déjà de me familiariser.

Je ne connaissais pas du tout le modbus mais ça à l'air costaud comme projet pour commencer ! Bon courage !

http://fr.wikipedia.org/wiki/Modbus#Couche_physique
--> n'est pas très explicite sur les différents cadencements

Je ne connais presque rien d'UML mais n'est-il pas dédié à l'orienté objet ? Peux-tu faire des graphes d'états avec ?

As-tu visité ce lien ? http://libmodbus.org/

J'ai 41 ans mais je suis débutant (bientôt 2 ans) car reconversion pro. Sortie avec un BTS IRIS. Le programme du BTS en UML est plus pour le comprendre que de voir toutes c'est possibilités, mais l'on passe pas mal de temps dessus avant le codage du projet, mais effectivement c'est plus orienté objet ce que n'est pas vraiment le C embarqué.

Toutefois il y a des diagrammes qui peuvent m’intéresser comme le diagramme d’état effectivement que l'on à vu en BTS. Mais je disais sa surtout pour trouver en faite un diagramme de fonctionnement.

Pour ce qui est du Modbus en RTU si j'ai bien compris mon chef et ce que j'ai lu. Il n'y a plus de bit de start et de stop, ces informations son données par une gestion du temps grâce à des poses qu'il faut que je calcul et détecte.

exemple: (dites moi si je me trompe) on reçois la 1ère trame, c'est le top je doit actionner un timer, si j'ai un vide de 3.5 fois le temps de transmission d'un mot c'est la fin de ma trame. Si j'ai un vide de plus de 1.5 fois le temps de transfert d'un mot, je dois considérer que c'est une nouvelle trame, et oublier ce qu'il y avait avant

C'est très courageux comme démarche. Je te souhaite une excellente réussite et d'apprécier ton nouveau métier ;)



Comme dit plus haut, je ne connais pas modbus. Faut fouiller un peu sur Internet, par exemple :
http://stielec.ac-aix-marseille.fr/c...oad/modbus.pdf
--> il y a des bits de start et stop pour constituer la trame. Les silences sont là pour séparer les trames. Il te faudra trouver comment cadencer les envois et réception sur l'UART. C'est cette cadence qui donnera le temps d'une trame et donc le temps de 3,5t entre 2 trames. En revanche, je ne sais pas ce qu'il doit se passer si on reçoit une nouvelle trame plus rapide que prévu.

http://www.modbustools.com/
--> des outils qui pourraient servir :)

http://www.rtaautomation.com/modbusrtu/
--> si tu te débrouilles en anglais, je te conseille de chercher aussi dans cette langue, tu trouveras sûrement plus d'informations.

Merci pour les infos. Quand à l'anglais il faut aussi que je bosse la dessus, je suis en formation actuellement mais par WallStreet Institute que je déconseille fortement, à moins d'aimer passer 2 heures devant un sitcom à l'eau de rose sous forme de photo.

En tout cas je vais regarder les sites proposés et chercher aussi en anglais, je me débrouille quand c'est technique.

C'est marrant ma soeur est aussi au Wall Street Institute et elle trouve ça bien ^^

N'hésites pas à revenir ici si tu as des doutes, je verrais si je peux t'aider.

Pour WallStreet, personnellement le début cela allait, cela m'a remis les bases en places, sortant d'un BAC pro EIE (Equipement et installation Electrique) de niveau très moyen, je n'avais pas pratiqué une seul fois en 20 ans donc il le fallait.
Au BTS j'était avec les élèves classique, donc la prof ne pouvait pas me coucou-né (quoi que j'aurais bien aimé :) ), je m'en suis sorti quand même au BTS avec la moyenne.
Mais pour WallStreet, me retrouver seul face à un écran cela me branche pas, de plus, de nombreuse incohérence existe entre le texte oraux et ce qui est écrit, mon plus grand souci c'est l'oral car je pense en français, et face au PC on ne fait que répéter donc cela ne me donne pas confiance. Ce n'est pas les 1 heures toutes les 6 heures de multimédia à plusieurs avec un prof qui récupère ce manque.

Il me reste 4 heures sur mon DIF j'ai tapé du point sur la table et la du coup se sera 4 heures de cours particulier mais bon mes 80 heures sont bouffé pour pas grand chose.

Donc je vais recherche un autre moyen pour apprendre l'anglais, ainsi que le français car je fais de nombreuses fautes, même si je me suis énormément améliorer depuis ma formation.

En tout cas je revis avec se nouveau métier, je ne vais plus au taf à reculons et les journées passent à une vitesse folle.


En ce qui concerne le Modbus, on attend une réponse de microship car il existe de nombreux bug dans leur IDE dont la version MPLAB X n'a pas corrigé.

Chacun son ressenti et ses attentes sur ce genre de cours. En tout cas, je comprends que ça te saoule d'utiliser ton DIF à une formation qui ne te convient pas !

En gros, tu es passé d'électricien à informaticien industrielle / embarqué si je comprends bien ?

MPLAB... J'ai refait un peu de PIC chez moi au début de l'année. J'ai été atterré par la pauvreté de cet IDE. Je n'ai pas utilisé la version X, faudrait que j'essaye. Quand je compare à Code Composer de TI, qui est basé sur Eclipse, c'est le jour et la nuit et pour moi, c'est un frein à l'utilisation des PICs.

Électricien industriel pendant 20 ans (technicien de test) à Informaticien industriel oui.
Depuis presque 2 ans j'ai fait que du soft PC en VB6 Rrrrr et j'ai apporté du .net avec le projet que j'ai eue au lycée qui est en fonctionnement au boulot maintenant les nouveaux soft sont développés en .net lorsque c'est possible. Une formation Android est prévu à la fin de l'année.

Mais surtout j'attendais vivement la fin de la journée tous les jours avant et aujourd'hui je suis obligé de mettre une alarme sur mon téléphone si non j'oublie d'aller chercher ma fille à l’école.
Cela change la vie d'avoir le cerveau qui se remet à fonctionner plutôt que de végéter et se rendre compte que l'on chute.

On c'est éloigner du sujet principal, mais j'encourage tout ceux qui on l’occasion de faire une formation qui leur plait, de le faire. J'en ai chi.. pendant 2 ans car cela n'a pas été simple, math/physique ouille..., mais je m'en suis admirablement sortie en terminant 2éme de l’académie Orléans/Tours (un peu de pommade) car je voulais ce changement et je me suis accroché, cela m'ouvre des portes et possibilités que je n'avais plus en électricité industriel qui se délocalise.
Mais lorsque l'on est en couple et 2 enfants, dure dure. Profiter en les jeunes, c'est bien plus dur après.


En ce qui concerne MPLAB je me suis bagarré avec aujourd'hui. Impossible d'ajouter des points d'arrêt, il me dit en gros que mon matériel en accepte plus alors qu'il y en a 0 de déposé. Obligé de redémarrer le PC pour espérer pouvoir en remettre 2 mais si j'ai le malheur de vouloir les déplacer c'est rebelote.
Ensuite il me dit que j'ai plus les drivers du boitier d'intercom, ou le débogage s’arrête tout seul sans raison.
C'est vraiment super chiant, je passe plus de temps à essayer de le faire marcher que de vérifier le programme.

Mon collègue et chef qui est encore en MPLAB 8 à moins de souci mais il compose depuis le temps avec les bugs. Il a remarqué d'ailleurs que les bug existant sont toujours présent dans le MPLABX ajouter a cela une lourdeur supplémentaire, et un archivage des fichiers avec des arborescences qui n'en finissent pas.

Bonsoir,

intéressant comme projet. La gestion des timings est en effet ce qu'il y a de plus délicat à programmer, le reste posant nettement moins de problèmes. Quoiqu'il reste toute la partie gestion des trames d'erreur.

Si tu programmes un maître modbus, le timing ne vont donc intervenir que sur la réception de réponses d'un esclave. Tu pourrais mesurer l'espace inter caractère à chaque réception d'un nouveau caractère, de manière à vérifier qu'il ne dépasse pas les 1,5*Tc, Tc étant le temps de transmission d'un caractère.

Connaissant l'espace inter trame, aucun esclave ne pouvant envoyer de nouveau message, le problème est réglé: tout nouveau caractère reçu est une condition d'erreur.

A moins que ton programme porte sur la programmation d'un esclave. Mais çà, tu ne le dis pas.

A+

Pour le moment il est en esclave.

On souhaite pouvoir interroger le système comme si l'on était en RS232 en face avant Afin de vérifier ou même modifier ces paramètres.

Le système est une supervision gérant notre armoire électrique, nos modules redresseurs, onduleurs, panneaux solaires, éoliennes etc....

D'accord, il s'agit d'un esclave et il sera le seul sur le bus, c'est bien cela?

Il faut donc gérer l'espace inter trame. Il doit être possible de le mesurer en lisant la valeur d'un compteur lors de la réception du dernier caractère d'une trame et en le relisant lors de la réception du 1er caractère de la trame suivante. Il faudra vérifier à cette occasion si le compteur n'a pas débordé plusieurs fois.

A+

C'est bon j'arrive à lire mes trames. Pour le moment je ne gère que la fin de trame, et pas les erreurs.


On ne fait pas exactement comme en RS232 contrairement à ce que je disais. J’interroge des registres et le système me répond. Mais je peste encore avec le mode débogage qui ne fonctionne pas. Ce n'est pas simple de bosser dans ces conditions. Actuellement j'active des sorties afin de vérifier le passage dans chaque méthode , pas top..

Bonjour megamario, bravo pour la reconversion, j'ai ton âge et je comprend...
Je développe sur pic depuis 10 ans+, et la moitié sur pic24. Il doit exister une raison simple pour se bug de breakpoint. Quel debugger ? MPLAB 8.x ? Windows ?
Les bits de config ont été contrôlés ? Horloge correcte ?

J'utilise mplab 8 pour le debug et x pour l'édition. X est un netbeans alors côté édition/compile c'est ok comme eclipse. C'est cependant encore buggé côté debug, trop de lenteur pour accéder au variables.
A+

Citation:

---

J'utilise mplab 8 pour le debug et x pour l'édition

---

Quand je disais plus tôt que MPLAB avait encore des progrès à faire, je n'imaginais pas une telle extrémité... Ca me remotive vachement à faire du PIC tout ça !

Citation:

---

Envoyé par pikadon

Bonjour megamario, bravo pour la reconversion, j'ai ton âge et je comprend...
Je développe sur pic depuis 10 ans+, et la moitié sur pic24. Il doit exister une raison simple pour se bug de breakpoint. Quel debugger ? MPLAB 8.x ? Windows ?
Les bits de config ont été contrôlés ? Horloge correcte ?

J'utilise mplab 8 pour le debug et x pour l'édition. X est un netbeans alors côté édition/compile c'est ok comme eclipse. C'est cependant encore buggé côté debug, trop de lenteur pour accéder au variables.
A+

---

Bonjour, en faite nous voulions passer au MPLABX pour la prise en charge d'un nouveau PIC (nouveau pour nous) aillant plus de mémoire, mais apparemment les dernières version de MPLAB8 le prend en charge. J'ai installé le 8 hier et effectivement c'est quand même bien plus stable et pas de souci de BreakPoint. Pour l’édition effectivement le X est plus intuitif, mais bon question d'habitude.
Vous arrivez à faire fonctionner les 2 en même temps? ou c'est ouverture, fermeture du projet à chaque fois. Etant débutant, je ne maîtrise pas encore assez pour écrire 200 lignes de code d'un seul coup sans vérifier le fonctionnement surtout en C, cela risque de devenir long d'ouvrir et fermer sans cesse le projet.

Par contre les bits de config et l'horloge, là je ne sais pas ce que c'est.

[Edit] J'oubliais, je suis sous XP

Bonjour,

Bon c'est OK j'arrive donc à lire mes trames parfaitement. J'avais des quelques timeout, mais en faite c’était mon interface de test avec le MAX232 qui merdouillait à 38400baud.

Par contre j'ai un petit souci de compréhension pour le calcul du timer.
J'utilise le Timer 1 avec la configuration suivante:

T1CONbits.TON = 0;
T1CONbits.TCS = 0;
T1CONbits.TGATE = 0;
T1CONbits.TCKPS = 0b11; //(Presdiviseur = 256)
TMR1 = 0x00;
PR1 = 15625; /*-- 100ms --*/
IFS0bits.T1IF = 0;
IEC0bits.T1IE = 1;

Lorsque j'active ou réactive le timer j'utilise la méthode suivante à la réception d'un octet:

Code:

---

1 2 3 4

T1CONbits.TON = 0; PR1 = ACM_Uart[UART_REAR].interFrameTout; TMR1 = 0x00; T1CONbits.TON = 1;

---

ACM_Uart[UART_REAR].interFrameTout est egale à:

Code:

---

ACM_Uart[UART_REAR].interFrameTout = 4*((CRYSTAL_FREQ/64L) / ACM_Config.uart[UART_REAR].baudrate);

---

4* au lieu des 3.5 standard ModBus.
CRYSTAL_FREQ = 40000000UL (donner par mon collègue)

Le résultat du calcul est de 0x40 à 38400 baud

Logiquement j'aurai du utiliser le Pres-diviseur (256) au lieu des 64L mais cela ne fonctionne plus je ne récupère uniquement que le 1er octet.

Entre chaque réception j'ai mesuré TMR1 à 0x28 environ.

Vous comprenez bien mon souci je pense, je ne voie pas comment calculer ce temps entre chaque trames. En temps que débutant dans le domaine embarqué.


En choisissant T1CONbits.TCS = 0; on utilise "Select internal instruction cycle clock" Donc je suppose que c'est les 40000000UL qu'il ma été donné. Mais je ne vois pas ou trouver l'information.

Voici un lien pour l'explication des timers pour mon Proc :
http://ww1.microchip.com/downloads/e...Doc/70244B.pdf.

Merci de votre aide pour m'éclairer un peu (beaucoup).