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]

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