Envoi d'informations sur MODBUS avec un PIC

[schmo]

salut,

Aprés une relecture un peu plus approfondie je ferais quelque rectificatifs à ce que j'ai écrit:
- La mise en buffer de la trame ce fait dans la routine 'ReadMBFrame' . buffer de 73 octets.
- L'attente de reception 'CheckRSInBuffer' est temporisée. Le traitement de la trame modbus ce fait si on ne recoit rien durant un certain temps.

Je m'attendais à trouver une gestion du temps avec timer d'ou ma confusion et ma réponse (trop) rapide. De plus je suis peut être un peu rouillé en C....

Donc si tu l'adapte pour du 18f, je dirais qu'il y a de forte chance que cela fonctionne. Tu auras juste à adapter les routines 'readRegResponse' et 'writeRegResponse' à tes besoins.
A+
-----

[invite3c35244f]

Un grand merci pour ton aide...

Je t'avouerai que je n'ai pas trop eu le temps de regarder le soft depuis la fin de semaine dernière, mais je compte m'y mettre prochainement.

Par contre quand tu dis:

Tu auras juste à adapter les routines 'readRegResponse' et 'writeRegResponse' à tes besoins.

Qu'entends tu par là?

Merci encore

[schmo]

salut,

Ben ouis, à un moment donné, il vas falloir que tu écrive tes mesure de T°, courant ou autre dans la trame réponse...

[invite3c35244f]

Ben ouis, à un moment donné, il vas falloir que tu écrive tes mesure de T°, courant ou autre dans la trame réponse...

Ah OK, ça je suis d'accord...

Merci et je te tiens au courant dès que j'avance un peu plus..

[invite3c35244f]

Bon, j'ai décidé de ne faire qu'une seule trame de réponse donc il y aura une seule trame de maitre:

COTE MAITRE: 01 03 00 64 00 08 B4 12
-> la trame sera sous cette forme:
ID esclave(hexa) = 0x01 (1)d
ID Fonct (hexa) = 0x03 (3)d
Addr de Début (hexa) = 0x64 (100)d
Longueur (reg) = 8 registres soit 16 octets
CRC = ? (J'ai du mal a le calculer-> mais le logiciel que j'utilise coté maitre (PC) pour la génération de la trame du maitre me le génère : 0xB4 | 0x12


COTE ESCLAVE:
-> la trame sera sous cette forme:
ID esclave(hexa) = 0x01 (1)d
ID Fonct (hexa) = 0x03 (3)d
Longueur de la data (oct) = 0x10 (16)d
Data1 = U = 4 octets
Data2 = I = 4 octets
Data3 = T = 4 octets
Data4 = C = 2 octets
Data5 = Rl = 2 octets
CRC = ? = 2 octets

->Comment gérer ça avec le soft?
J'ai regardé un peu le principe, et voila ce que j'en ai déduit:

ReadMBFrame() : Lecture de la trame Maitre dès qu'il y a une réception -> On en sort le type de la fonction souhaité par le maitre.
buffer[0] -> ID esclave
buffer[1] -> ID Fonction
buffer[2] -> Addr start high
buffer[3] -> Addr start low
buffer[4] -> Longueur high
buffer[5] -> Longueur low
buffer[6] -> CRC low
buffer[7] -> CRC high


writeBadRequest(c) Si la fonction demandé est incorrect(0x05), on renvoi un trame de ce type:
ID esclave(hexa) = 0x01 (1)d -> buffer[0]
ID Fonct (hexa) = 0x80+0x03 (131)d -> buffer[1]
DATA1 = 0x05 -> buffer[2]
CRC low= 0x? -> buffer[3]
CRC high= 0x? -> buffer[4]

readRegResponse() Si la fonction est égale à 3

writeRegResponse() Si la fonction est égale à 16

Et voila... j'ai essayé, mon PIC reçoit bien la trame du maitre avec les bonnes valeurs (visualisation des valeurs après la fonction ReadMBFrame()).
Mais après je suis un peu perdu, a mon avis, je dois travailler avec la fonction readRegResponse() et l'adapter pour qu'elle envoi toutes mes valeurs:
Data1 = U = 4 octets
Data2 = I = 4 octets
Data3 = T = 4 octets
Data4 = C = 2 octets
Data5 = Rl = 2 octets (Rl = états des 4 relais)

Mais comment faire...

Je vais continuer dans ce sens et essayer de comprendre ces 2 dernières fonctions, mais un petit coup de pouce serait la bien venu...

Merci en tout cas d'avoir pris le temps de lire toute mon explication et Merci d'avance à ceux répondront ou celui (Schmo) qui me répondra..

[invite3c35244f]

Bonjour,

bon j'ai réussi a comprendre un peu la fonction readRegResponse() , en faite, j'avais pas fais attention que le programme servait a communiquer en liaison MODBUS, mais aussi avec une mémoire externe!! d'ou les fonctions I2C... Je peux donc supprimer toutes les fonctions I2C qui servent a la gestion / récupération de données dans la mémoire...
donc dans la fonction readRegResponse() :

void readRegResponse(void) //response for modbus 03 function (read registers)
{
unsigned char i;
T.bytes.lowByte = buffer[3]; 
T.bytes.highByte = buffer[2]; 
T.integer*=2;
buffer[2] = buffer[5]*2;

for (i=0; i<buffer[2]; i++)
     {
	startI2C();
	writeI2C(0xA0);
	writeI2C(T.bytes.highByte);	//T.bytes.highByte
	writeI2C(T.bytes.lowByte);	//T.bytes.lowByte
	stopI2C();
	startI2C();
	writeI2C(0xA1);
	RCEN = 1;
	buffer[i+3] = readI2C();
	RCEN = 0;
        T.integer++;
      }
CRC16(buffer[2]+3,0);				// Création CRC 16
for (i=0; i<buffer[2] + 5; i++)		// --> Envoi de la trame MODBUS 
writeRS(buffer[i]);					//
}

Je peux la réduire à :

void readRegResponse(void) //response for modbus 03 function (read registers)
{
unsigned char i;
T.bytes.lowByte = buffer[3]; 
T.bytes.highByte = buffer[2]; 
T.integer*=2;
buffer[2] = buffer[5]*2;

//
/// ->> J'insère ici les valeur que je souhaite dans les différents buffers ?
//
CRC16(buffer[2]+3,0);				// Création CRC 16
for (i=0; i<buffer[2] + 5; i++)		// --> Envoi de la trame MODBUS 
writeRS(buffer[i]);					//
}

Ce que je souhaite faire est-il bon?
Et es ce que je peu supprimer la fonction writeRegResponse() vu que je ne m'en sert pas, je dois juste gérer la fonction 03 ?

Merci d'avance

[invite3c35244f]

Bon, je n'ai pas de réponse, mais j'avance à grand pas!!!

J'ai réussi a réaliser mon envoi de trame de requête, je reçois bien ma trame de réponse, mais par contre, j'ai supprimer la fonction 16, je garde donc seulement les fonctions 03 et la fonction d'erreur.

Et ça marche parfaitement...(a moins que tu vois une erreur dans ce que je dis, et qui ne serais pas correct vis a vis du protocole MODBUS...?)

Sincèrement, je te remercie infiniment pour ton aide, car sans toi, j'y serai encore...
Mille Merci...

[schmo]

salut,

Ok pour ta fonction readRegResponse() tu mets tes data à partir de buffer[3].
Pour la fonction d'écriture, si tu n'en as pas besoin, tu peux la supprimer. tu répondra par une trame d'erreur (fonction demandé incorrecte ) si jamais tu reçoit une trame d'écriture.

==> comme tu l'as visiblement fait (vus ton dernier post)

A+

[invite3c35244f]

C'est ce que j'ai fais...
Par contre, dans la trame d'erreur, est ce qu'il y a des codes a respecter?La trame d'erreur est elle la meme en fonction du type d'erreur, si il s'agit d'une erreur adresse de l'esclave ou si il s'agit d'une erreur de fonction?
Par exemple si l'adresse ou la longueur de la trame demandé est incorrect, comment je dois traiter la demande?
exemple, si le maitre me demande une donnée qui commence a l'adresse 200 et que la mienne commene a l'adresse 100, qu'elle sera la trame de réponse?


Merci encore pour ton aide...

[schmo]

salut,

Dans la fonction ReadMBFrame() :
Adresse registre à lire = buffer[2],buffer[3] (buffer[2] est le MSB)
Nombre de registres à lire = buffer[4],buffer[5] (buffer[4] est le MSB)

tu accepte la trame si:
1/ le nombre de registres à lire est >0 et <= 8,
2/ l'adresse registre à lire >=100 et <=108,
3/ (adresse registre + (nombre de registre-1)) <= 108

si ce n'est pas le cas la fonction ReadMBFrame() retourne la valeur 2. Ce qui permet d'envoyer une trame d'erreur writeBadRequest(c) avec comme type d'erreur 'Erreur d'adresse'.

C'est bon, tu es quasiment arrivé à la fin...tu touches au but..

[invite3c35244f]

C'est bon, tu es quasiment arrivé à la fin...tu touches au but..

Parfait parfait... ça marche parfaitement...
Je rajouterais des fonctions si j'en ai le besoin un jour...mais je crois que j'ai bien compris le principe... Encore Merci

A bientot

[invite3c35244f]

Bonjour...

J'ai un petit problème, mon soft marche parfaitement avec la carte PICDEM2+ (liaison RS232), mais voila, avec une autre carte avec une liaison RS485, ce la ne marche pas...

Alors tout d'abord, connais tu la connectique exact pour le protocole MODBUS RS485 en 2 fils (connecteur SUBD 9pt)?

J'ai suivi cette documentation:
http://www.modbus.org/docs/Modbus_ov...line_V1_02.pdf
à la page 29/44



Merci d'avance

[schmo]

salut,

Sur un bus rs485, il ne peut y avoir qu'un emetteur à la fois. les autres appareils connectés doivent être en reception. Tout ça pour dire que par défaut l'appareil connecté au bus est en récéption. Il passe en émission seulement le temps de transmettre sa trame réponse, il repasse ensuite en réception. C'est pour cela qu'il y a les commandes /RE et DE sur les convertisseur de signaux RS485 (genre SN75176, MAX487,etc..)
Il faut donc que tu controle ces signaux...
En général, ils sont reliés ensemble et reliés à une sortie IO du pic. (sortie à 1 tu est en emetteur, sortie à 0 tu es en recepteur).
Pour le cablage, il faut s'assurer qu'il n'y ait pas d'inversion entre les lignes A et B.

[invite3c35244f]

Merci Schmo,

j'avais bien fais mon cablage (DE et RE relié ensemble et le tout cablé sur une sortie de mon PIC), mais j'ai complètement oublié de rajouter ce pilotage pour la transition RS232 -> RS485.

Donc, je suis toujours en réception (sortie du PIC à 0) et dès que la réception de mon message est terminé, et que je suis prêt a envoyer le mien, j'active mon transmetteur, et une fois l'envoi terminé, je le remet en réception.

Je vais essayer tout ça.
En ce qui concerne l'inversion des lignes A et B, j'ai moyen de les inverser "physiquement" au cas où.

Merci encore...je vais y arriver, j'y suis presque!!!
Bonne journée

[invite3c35244f]

Bonsoir à tous...

bon voila, je suis arriver a mettre en oeuvre ce que je souhaitais faire, mais par contre, maintenant j'ai compliqué la chose, j' ai sur le "réseau" 1 maitre et 2 esclaves, et je souhaitais savoir si il y avait des regles a respecter au point de vue de l'envoi des trames de requêtes coté "maitre",y a t'il une procédure particulière a suivre car voila ce que je pensai faire:
1 -> MASTER :Envoi trame de requête pour SLAVE 1
2 -> MASTER :Attente de réception de la trame de réponse du SLAVE 1
3 -> MASTER :Envoi trame de requête pour SLAVE 2
4 -> MASTER : Attente de réception de la trame de réponse du SLAVE 2

et ainsi de suite... ou alors le maitre peut il réaliser succesivement les 2 envois des requêtes destinées à l'esclave 1 et 2, et attendre ensuite leur réponse?

y a t'il un principe a respecter ?

Merci d'avance et bonne soiré a tous

[schmo]

salut,

La sequence que tu as décrite est la bonne. Le maitre procède de manière séquentielle avec les différents esclaves.
Il interroge l'esclave 1, attends sa réponse, si il n'y a pas de réponse: soit l'esclave est absent, soit il y a eu une erreur de communication. Il passe ensuite à l'esclave suivant....

Cette façons de faire permet d'avoir à chaque fois une communication entre 1 maitre et 1 esclave. La seule fois ou le maitre s'adresse à tous les esclave c'est avec une requette 'broadcast', mais dans ce cas les esclaves n'on pas de réponse à fournir..

A+

[invite3c35244f]

Merci pour l'information schmo,

par contre, en ce qui concerne la requête "broadcast", j'ai lu une documentation du site www.modbus.org: (en page 7)

http://www.modbus.org/docs/Modbus_ov...line_V1_02.pdf

Il y a 2 modes : Unicast -> "mode com normale" et le mode Broadcast, par contre, je ne comprend pas le principe...

Peux tu m'en dire un peux plus??

Merci d'avance et bonne continuation

[schmo]

salut,

Le mode UNICAST correspond au mode normal de fonctionnement d'un maitre et de ses esclaves:
- le maitre envoi une requête à une adresse spécifique à un esclave
- l'esclave repond
-> la transaction est terminée, le maitre peut passer à l'esclave suivant

Le mode BRODCAST est une manière de communiquer particulière:
- le maitre adresse une requête à l'adresse '0'
- TOUT les esclaves recoivent cette requête, la traite MAIS ne répondent pas..(sinon ce serait un beau bordel sur la ligne.!)
c'est comme si le maitre ecrit dans un registre qui est à la même adresse dans tous les esclaves.

Je sais pas si cette fonction est trés utilisée (la grosse majorité des appareils modbus que j'ai fait sont en lecture seulement. Donc le brodcast est impossible)

A+

[invite3c35244f]

Merci schmo,

en fait cette requête Broadcast n'a pas trop d'intéret... je ne vais donc pas m'attarder dessus...

Merci encore schmo pour ton expérience... bonne continuation

[invite3c35244f]

Bonjour à tous,

je souhaiterai rendre mon petit système plus "polyvalent", c'est a dire de pouvoir modifier le type de communication en configurant des paramètres tel que :
-numéro d'esclave
-vitesse
-la parité (impaire / paire / aucune)
-le bit de stop (1 ou 2)

J'ai donc étudié un peu le principe, et en ce qui concerne le numéro d'esclave ou la vitesse de transmission, j'ai trouvé comment faire cela.
Par contre, qu'en est'il pour la parité et le bit de stop? sont'il gérer par le module EUSART?

Pour le moment, je n'ai aucune parité et un seul bit de stop

Merci d'avance pour vos conseils

[invite3c35244f]

Bonjour,

quelqu'un saurait répondre à cette question ?

-La parité et le bit de stop sont'il gérer par le module EUSART?
-Si c'est n'est pas le cas, comment peut'on agir sur ces 2 bits?

Merci d'avance

[RISC]

Salut,

Comme c'est expliqué dans la datasheet, la parité n'est pas gérée en HW mais si le 9e bit de data n'est pas utilisé, il peut être utilisé pour la parité qui doit alors être calculée de façon logicielle.
Pour les bits de stop je crois que c'est figé à 1.

a+

[invite3c35244f]

Merci RISC pour cette réponse,

je vais essayé de retrouver dans la documentation le moment ou il parle du 9ème bit et essayer de trouver des infos sur le bit de stop.

[invite3c35244f]

Bonjour à tous,

je me permet de déterrer ce sujet, car je me suis relancer dans la communication MODBUS, et je souhaiterai rajouter la fonction d'écriture...

Je vais re-regarder les exemples que vous m'aviez proposé, mais en rapidement, si je reçois une trame d'écriture de la part du maitre, dois je renvoyer une trame de réponse de bonne réception ou autre?

Merci d'avance

[schmo]

salut,

Oui il faut que tu retourne une réponse aux requête d'écriture.

La réponse à une requête avec le code fonction 0x06. C'est à dire une écriture d'un registre. contient:
... code fonction, adresse du registre, valeur écrite ....

La réponse à une requête avec le code fonction 0x10. C'est à dire une écriture de n registres contient:
... code fonction, adresse du 1er registre, nombre de registre écrit

regarde les spécifications modbus sur http://www.modbus.org/specs.php
pour avoir des détails sur les fonctions, requête, réponse.

A+

[invite3c35244f]

Merci pour cette information !!!
J'ai regardé la doc que tu m'as conseillé, et j'ai trouvé ce que je voulais...

Merci encore pour ton aide

[invite3c35244f]

Bonjour,

Re-déterrage de sujet...

En effet, ma liaison RS422 protocole MODBUS fonctionne parfaitement en Lecture/Ecriture, mais je me pose encore une question...

La configuration de ma liaison est actuellement de type asynchrone sans bit de parité - Que dois je faire au niveau configuration des registres du PIC et structure des trames (émission/réception) pour que la liaison soit asynchrone avec un bit de parité (pair)?

Merci d'avance,

ps: je me suis renseigné sur la liaison avec ce lien:
http://www.tavernier-c.com/serie.htm

[schmo]

salut,

l'uart du 18f peut être configurée pour transmettre 9 bits (8b data + parité).
Le choix du nombre de bit à envoyer est dans le registre TXSTA: bit6 (TX9)=1 et le bit0 (TX9D) correspond au 9em bit.
Pour la réception, c'est les bit6 (RX9) et bit0 (RX9D) dans le registre RCSTA

Je ne sais pas par contre si des routines C existent dans les compilos pour gérer l'uart en 9bit. Tu seras peut être obligé d'écrire toi même les routines pour calculer la parité et pour envoyer et recevoir les 9bits.

A+

[sam380]

Bonjour,

est-il possible de faire la meme chose sur le pic mais en tcp/ip, je veux dire sans grand changement.
est ce une bonne idee de partir d'un code utilisant une liaison serie ? ou bien y-a-t-il trop de modifications a faire.

Sinon est-ce que vous savez s'il y a du code existant a reprendre utilisant tcp ?

Merci beaucoup d'avance