Discussion :

[naspen]

Bonjour à tous,

Je dois développer une appli Windev qui permette une lecture périodique des entrées d'un automate via Modbus TCP. Je dispose pour cela d'une dll me permettant d'appeler les fonctions de connexion et de lecture ( pp.13 et 18)http://www.wago.com/wagoweb/document...2/m931200e.pdf).

Ma première idée est la suivante :Après avoir établi la connexion Modbus TCP (lors d'un clic sur un bouton Connexion qui appelle la fonction MBTConnect) ,j'appelle une procédure automatique qui toutes les 100 ms lit la valeur d'un bit (procédure lect1() avec les commentaires).
Cette méthode ne fonctionne pas,je récupère à chaque fois dans nLectureregistreentre un code d'erreur indiquant que la connexion a été perdue.

J'ai tenté une autre approche qui consiste à se connecter et se déconnecter à chaque fois qu'on veut réactualiser la valeur d'une entrée (supression des barres de commentaires de lect1()), et là ça fonctionne.

C'est très contraignant de devoir établir une connexion différente pour chaque entrée lue.
Le problème se situe t-il au niveau du handle ?
Ne serait-il pas possible d'établir une connexion une fois pour toutes et de lire périodiquement les entrées désireés ensuite ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
 
PROCEDURE lect1()//appeleé toutes les 100ms
 
//nConnect est un entier sur 8 octets
//szhostadress est une chaîne  sur 100
//nPort est un entier 
//bUsetcporudp est un booléen
//nRequesttimeout est un entier sur 2 octets 
 
//szhostadress="192.168.1.4"
//nPort=502
//bUsetcporudp=True
//nRequesttimeout=1000000
 
//nConnect=API("MBT.DLL","MBTConnect",&szhostadress,nPort,bUsetcporudp,nRequesttimeout,&nHsocket)
 
nLectureregistrentree est un entier
nTabletype est un entier sur 1 octet
nAdressedebut est un entier sur 2 octets
nNbits est un entier sur 2 octets
nPreadbuffer est un entier système
DI1 est un booléen
nTabletype=1
nAdressedebut=0
nNbits=1
 
 
nLectureregistrentree=API("MBT.DLL","MBTReadCoils",nHsocket,nTabletype,nAdressedebut,nNbits,&nPreadbuffer,Null,0)
SI nLectureregistrentree=0 ALORS
	DI1= nPreadbuffer
	SAI_Saisie1=nPreadbuffer	
SINON
	Erreur("erreur lors de la lecture")	
FIN
 
//API("MBT.DLL","MBTDisconnect",nHsocket)

Merci d'avance

[Redg9]

C'est très contraignant de devoir établir une connexion différente pour chaque entrée lue.

En effet, pourquoi ne pas essayer de mettre en place un singleton pour ta connexion ?

[Grmmml]

Salut,

Pour fonctionner, l'appel à MBTReadCoils a besoins d'un handle valide, i.e. d'une valeur de nHsocket initialisée par l'appel à MBTConnect.

La variable nHsocket est-elle définie globale ? Si non, essaye en la déclarant globale qu'elle soit connue de tout le monde.
Sinon tu peux aussi la passer en paramètre à la fonction lect1

Bob.

[naspen]

En effet, pourquoi ne pas essayer de mettre en place un singleton pour ta connexion ?

J'ignorais cette possibilité. Une recherche rapide m'a appris que le singleton permettait de créer une instance unique de classe. Je vais explorer cette piste, n'étant pas très au fait de la POO sous Windev.

La variable nHsocket est-elle définie globale ? Si non, essaye en la déclarant globale qu'elle soit connue de tout le monde.
Sinon tu peux aussi la passer en paramètre à la fonction lect1

Oui la variable nHsocket est bien définie globale et poutant il semble que sa valeur ne soit valide que le temps d'une seule lecture. Je vais essayer de la passer en paramètre de lect1() et voir ce que ça donne.

[naspen]

Après une mise en standby (imposée) du projet, je dois à nouveau me concentrer sur ce problème de connexion.
En passant nHsocket en paramètre, la connexion est tout de même perdue dès la deuxième tentative de lecture.
Le singleton répond-il à cette problématique? Pour le mettre en place sous Windev, dois-je créer une nouvelle classe Singleton et instancier un objet de cette classe en rapport avec le handle nHsocket ?