Discussion :

[naspen]

Bonjour à tous,

Afin d'établir une connexion depuis Windev avec un automate je dois faire appel à une DLL externe depuis Windev mais ça coince au niveau des paramètres à passer à la fonction MBTConnect dont voici le prototype :

Code :

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

1
2
3
4
5
6
7
LONG MBTConnect(
IN LPCTSTR szHostAddress, /* remplacé par un entier système (censé remplacer les pointeurs)  et une chaîne (2ème essai)*/
 
IN WORD port, // remplacé par un entier sur deux octets
IN BOOL useTCPorUDP, //remplacé par un booléen
IN DWORD requestTimeout,//remplacé par un entier
OUT HANDLE *hSocket);//remplacé par un entier système

A l' exécution l'appel de la DLL déclenche une erreur fatale sûrement due à un mauvais typage des paramètres mais je ne sais dire le(s)quel(s).

Merci d'avance

[Grmmml]

Je dirais qu'il faut écrire quelque chose du genre :

s

Code :

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

1
2
3
4
5
6
7
8
9
zHostAddress est une chaine fixe sur 100    // essentiel pour que ca corresponde au C */
 
LONG MBTConnect(
IN LPCTSTR szHostAddress, /* ecrire : &szHostAddress*/
 
IN WORD port, // remplacé par un entier sur deux octets : Ok
IN BOOL useTCPorUDP, // remplacé par un booléen : Si ca ne fonctionne pas, utilise un entier
IN DWORD requestTimeout,//remplacé par un entier : Ok
OUT HANDLE *hSocket);//remplacé par un entier système : il faut plus d'information sur la spec pour connaitre le type Handle et savoir s'il faut au préalable allouer l'espace nécessaire ou si un simple entier suffit

Bob.

[naspen]

Merci Bob de ta réponse. Je tente ça dès demain. Concernant le handle il est précisé qu'il se rapporte à la connexion établie. Son type ne semble pas explicitement indiqué (p.13) http://www.wago.com/wagoweb/document...2/m931200e.pdf.

[Grmmml]

Oups, je corrige une petite erreur, il faut écrire

Code :

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

1
2
 
zHostAddress est une chaine sur 100

Sans le mot "fixe"

Bob.

[naspen]

Alors je viens de tester la solution proposée et effectivement ça marche ! C'est le cas également avec une chaîne fixe.
Cependant je bute maintenant sur la déconnexion.
Je suppose que la handle crée lors de l'appel de la fonction MBTConnect doit être passé en paramètre d'entrée de la fonction MBTDisconnect.

Code :

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

1
2
3
 
LONG MBTDisconnect(
IN HANDLE hSocket);

J'ai donc déclaré hsocket en tant que variable globale à ma fenêtre pour le passer à la fonction MBTDisconnect mais le code d'erreur renvoyé indique un handle non valide :

Code :

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

1
2
3
4
 
Disconnect est un entier
Disconnect=API("MBT.DLL","MBTDisconnect",&hsocket)
Info(Disconnect)

Faut-il procéder autrement ?

[Grmmml]

Le code est presque bon, il ne faut juste pas mettre l'esperluette "&" dans l'appel à disconnect.

Code :

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

1
2
 
Disconnect=API("MBT.DLL","MBTDisconnect",hsocket)

Par contre, pour que ça fonctionne, je pense que pour la connexion il faudrait utiliser "&hsocket" :

Code :

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

1
2
 
MBTConnect (&szHostAddress, port, requestTimeout, &hSocket)

Bob.

[naspen]

Merci beaucoup une fois encore c'est bien ça! Je n'avais pas remarqué qu'il ne fallait pas passer le paramètre hsocket par adresse...

[Grmmml]

De rien, c'est avec plaisir

Si tout fonctionne, pense à marquer la discussion [Résolu] avec le bouton qui va bien

Bob.

[naspen]

Je crois que je suis loin d'en avoir fini avec cette DLL. J'arrive bien à récupérer sur l'IHM Windev les valeurs de mes entrées/sorties numériques, par contre les entrées analogiques posent problème.
- Je souhaite lire la valeur de la première entrée analogique %IW0, donc à l'adresse Modbus 0X0000 comme indiqué içi (pp.138 et 125)http://www.wago.com/wagoweb/document...2/m084200e.pdf
- tabletype vaut 3 comme indiqué içi p.30 http://www.wago.com/wagoweb/document...2/m931200e.pdf
- La lecture souhaitée étant synchrone, les deux paramètres restant doivent valoir Null et 0 (p.16 du lien ci-dessus) .

La valeur que je récupère via le pointeur nPreadbuffer doit donc être l'image de mon entrée analogique. J'ai testé avec une boucle de courant 4-20 mA et j'obtiens sur mon IHM Windev des valeurs complètement incohérentes, tandis que la variable automate %IW0 évolue correctement entre 0 et 65535.

La Lecture du registre d'entrée se fait via la fonction MBTReadregisters :

Code :

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

1
2
3
4
5
6
7
8
9
 
C: LONG MBTReadRegisters(
IN HANDLE hSocket,
IN BYTE tableType,
IN WORD dataStartAddress,
IN WORD numWords,
OUT LPBYTE pReadBuffer,
OPTIONAL IN MBTReadCompleted fpReadCompletedCallback
OPTIONAL IN DWORD callbackContext);

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
 
 
nLectureregistrentree est un entier
nTabletype est un entier sur 1 octet
nAdressedebut est un entier sur 2 octets
nNbmots est un entier sur 2 octets
nPreadbuffer est un entier système
 
nTabletype=3
nAdressedebut=0
nNbmots=1
 
 
nLectureregistrentree=API("MBT.DLL","MBTReadRegisters",hsocket,nTabletype,nAdressedebut,nNbmots,&nPreadbuffer,Null,0)
Info(nPreadbuffer)

Je pense qu' à nouveau je ne passe pas correctement les paramètres.

[Grmmml]

L'utilisation de "&" est Ok.
Reste peut-etre juste à utiliser "0" à la place de "null"

Question supplémentaire, quelle est la taille de la donnée attendue ?
Si la taille est supérieure à 1 octet, alors probablement que pReadBuffer est un pointeur sur un buffer (donc une suite d'octet) dans lequel est stocké le résultat.
Auquel cas il faut écrire quelque chose du genre

Code :

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

1
2
 
nPreadbuffer est un buffer sur 10

Bob.

[naspen]

La donnée attendue est sur un mot, soit 2 octets.
La valeur que je récupère maintenant dans pReadbuffer est une suite de 2 caractères ou symboles variables ("?a","A0" ou un carré suivi d'un "a",etc) selon le courant en entrée.
J'ai à tout hasard tenté de récupérer une valeur numérique avec la fonction Val mais la valeur retournée reste invariablement 0.

[Grmmml]

La donnée attendue est sur un mot, soit 2 octets.
La valeur que je récupère maintenant dans pReadbuffer est une suite de 2 caractères ou symboles variables ("?a","A0" ou un carré suivi d'un "a",etc) selon le courant en entrée.
J'ai à tout hasard tenté de récupérer une valeur numérique avec la fonction Val mais la valeur retournée reste invariablement 0.

Donc ça semble fonctionner, le problème est juste dans l'interprétation du contenu de pReadBuffer.
Je serais plutôt partisan d'utiliser

Code :

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

1
2
 
pReadBuffer est un Buffer sur 2

puis de décoder à la main les valeurs du buffer. Pour voir le contenu essai ça

Code :

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

1
2
3
 
trace(pReadBuffer[[1]])
trace(pReadBuffer[[2]])

Bob

[naspen]

J'ai récupéré le contenu de pReadbuffer avec comme courant d'entrée 4,2mA, 5mA, 16mA et 20mA. Le décodage de l'information supposerait de connaître le système de numération utilisé : ça semble içi plutôt aléatoire, quoiqu'il y ait une ressemblance avec certains symboles utilisés dans Word.
L'exploitation des données telles quelles me semble vraiment compliquée.

[Grmmml]

J'ai récupéré le contenu de pReadbuffer avec comme courant d'entrée 4,2mA, 5mA, 16mA et 20mA. Le décodage de l'information supposerait de connaître le système de numération utilisé : ça semble içi plutôt aléatoire, quoiqu'il y ait une ressemblance avec certains symboles utilisés dans Word.
L'exploitation des données telles quelles me semble vraiment compliquée.

En fait c'est je pense, relativement simple. Par contre je ne pensais pas qu'il convertirais en ASCII pour affichage. As-tu bien utilisé le code que je proposais avec le type Buffer ?

Si oui, essaie les différentes solutions suivantes

Code :

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

1
2
3
4
 
trace(ASC(pReadBuffer[[1]]), ASC(pReadBuffer[[2]]))
trace(numeriqueverschaine("d", pReadBuffer[[1]]), numeriqueverschaine("d", pReadBuffer[[2]])
trace(numeriqueverschaine("x", pReadBuffer[[1]]), numeriqueverschaine("x", pReadBuffer[[2]])

Pour valider les résultat il faut aussi que tu ais une idée des plages de valeur attendue ?

Bob.

[naspen]

Oui le type buffer sur 2 a bien été utilisé. La plage de valeurs attendue s'étend de 0 à 65535.
Ce serait vraiment surprenant que les données envoyées soient converties en ASCII.
Week-End oblige je vais devoir attendre lundi avant d'essayer ta solution.

Merci encore pour ton aide ô combien précieuse

[naspen]

Je viens de tester et une fois encore tu as tapé dans le mille !
Après décodage pReadBuffer[1] et pReadBuffer[2] contiennent les 2 octets indiquant la valeur de mon entrée analogique. En appliquant un décalage de 7 bits à pReadBuffer[1] qui est l'octet de poids fort et en l'ajoutant à pRreadBuffer[2] je retrouve la valeur de mon entrée analogique avec une plage de variation de 0 à 65535.

Vraiment....Merci pour ton aide!

[Grmmml]

Je viens de tester et une fois encore tu as tapé dans le mille !
Après décodage pReadBuffer[1] et pReadBuffer[2] contiennent les 2 octets indiquant la valeur de mon entrée analogique. En appliquant un décalage de 7 bits à pReadBuffer[1] qui est l'octet de poids fort et en l'ajoutant à pRreadBuffer[2] je retrouve la valeur de mon entrée analogique avec une plage de variation de 0 à 65535.

Vraiment....Merci pour ton aide!

Vraiment, pas de quoi, c'est toujours un plaisir.

Pense à marquer le sujet "Résolu"

Bob