|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Débuté par René ELEX, 21 oct. 2019 18:01 - 8 réponses |
| |
| | | |
|
| |
Posté le 21 octobre 2019 - 18:01 |
Bonjour à Tous
Besoins d'aide pour un afficheur PRECIA MOLEM i20
avec le code suivant
//------------------------------------------------------------------------------
sDataRead est une chaîne = ""
Com_ouvre est un booléen = sOuvre(Port, 2000, 2000,sTimeoutDéfaut, Vrai)
sFixeParamètre(Port, res_vitesse,Parité,Bits_Données, Bits_Stop)
//ligne en exa pour commander la balance a renvoyer une trame
("011039394D353c0D0A")
Ligne_a_ecrire est une chaîne
=(Caract(01)+Caract(16)+Caract(57)+Caract(57)+Caract(77)+Caract(53)+Caract(60)+Caract(13)+Caract(10))
SI sEcrit(Port,(Ligne_a_ecrire)) = Faux ALORS
BOUCLE
SI sDansFileSortie(Port) = 0 ALORS SORTIR
FIN
// il ne semble pas y avoir de problème d'ecriture
Info("Fin de l'écriture")
FIN
sDataRead = sLit(Port,2000)
SI sDataRead = "" ALORS
SI OKAnnuler("erreur lecture") ALORS
Sais_res="Erreur"
FIN
SINON
SI OKAnnuler("succes") ALORS
Sais_res=sDataRead
FIN
FIN
sFerme(Port)
//------------------------------------------------------------------------------
Mon Code renvoi toujours Erreur de lecture de la réponse de la balance
L’écriture de la demande a l'air correcte
Le test dans le terminal de test de PRECIA
avec la demande 011039394D353c0D0A
Me retourne bien le résultat de demandé
Poids net poids brut tare et id du pesage
Merci pour votre aide
--
R ELEX |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
940 messages
Popularité : +66 (68 votes) |
|
Posté le 22 octobre 2019 - 10:59 |
bonjour René,
la trame : 011039394D353c0D0A permet peu être effective de lire le poids pour votre balance, je ne connais pas ce modèle, mais je pense qu'il doit y avoir des trames d’initialisation , avant de pouvoir lire un poids.
il faudrait contrôler la documentation, mais il doit y avoir une séquence d'initialisation de la communication avec la balance, puis une fois cette étape réalisée, vous devriez pouvoir envoyer votre trame....
à vérifier... |
| |
| |
| | | |
|
| | |
| |
Posté le 22 octobre 2019 - 14:46 |
Le 22/10/2019 à 08:59, Christophe a écrit :
bonjour René,
la trame : 011039394D353c0D0A permet peu être effective de lire le poids
pour votre balance, je ne connais pas ce modèle, mais je pense qu'il
doit y avoir des trames d’initialisation , avant de pouvoir lire un poids.
il faudrait contrôler la documentation, mais il doit y avoir une
séquence d'initialisation de la communication avec la balance, puis une
fois cette étape réalisée, vous devriez pouvoir envoyer votre trame....
à vérifier...
Bonjour
Merci beaucoup Christophe
dans Le terminal de test fournie par precia
011039394D353c0D0A en EXA la séquence ini est intégrée
permet d'obtenir cette réponse sur deux lignes
95M5<
0406820100049.0kg 0200049.0kg 0300000.0kg 99000123:
Ma ligne de code est la suivante
Ligne_demande est un Buffer
=Caract(0x01)+Caract(0x10)+Caract(0x39)+Caract(0x39)+Caract(0x4D)+Caract(0x35)+Caract(0x3c)+Caract(0x0D)+Caract(0x0A)
C'est peut être ma demande qui n'est pas correcte
Qu'en pensez vous
--
R ELEX |
| |
| |
| | | |
|
| | |
| |
Posté le 22 octobre 2019 - 14:46 |
Le 22/10/2019 à 08:59, Christophe a écrit :
bonjour René,
la trame : 011039394D353c0D0A permet peu être effective de lire le poids
pour votre balance, je ne connais pas ce modèle, mais je pense qu'il
doit y avoir des trames d’initialisation , avant de pouvoir lire un poids.
il faudrait contrôler la documentation, mais il doit y avoir une
séquence d'initialisation de la communication avec la balance, puis une
fois cette étape réalisée, vous devriez pouvoir envoyer votre trame....
à vérifier...
Bonjour
Merci beaucoup Christophe
dans Le terminal de test fournie par precia
011039394D353c0D0A en EXA la séquence ini est intégrée
permet d'obtenir cette réponse sur deux lignes
95M5<
0406820100049.0kg 0200049.0kg 0300000.0kg 99000123:
Ma ligne de code est la suivante
Ligne_demande est un Buffer
=Caract(0x01)+Caract(0x10)+Caract(0x39)+Caract(0x39)+Caract(0x4D)+Caract(0x35)+Caract(0x3c)+Caract(0x0D)+Caract(0x0A)
C'est peut être ma demande qui n'est pas correcte
Qu'en pensez vous
--
R ELEX |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
940 messages
Popularité : +66 (68 votes) |
|
Posté le 23 octobre 2019 - 16:53 |
rebonjour René,
désolé du temps de réponse !!
je viens de revoir votre code,
vous faites un :
SI sEcrit()=Faux ALORS
FIN
sauf que sEcrit() ne retourne pas un booléen !
=> https://doc.pcsoft.fr/fr-FR/?3062009&name=sEcrit
Ligne_a_ecrire est une chaîne=Caract(0x01)+Caract(0x10)+Caract(0x39)+Caract(0x39)+Caract(0x4D)+Caract(0x35)+Caract(0x3c)+Caract(0x0D)+Caract(0x0A)
sEcrit(Port,(Ligne_a_ecrire))
BOUCLE
SI sDansFileSortie(Port) = 0 ALORS SORTIR
FIN
Info("Fin de l'écriture")
pour la lecture
_nb_octet_dispo est un entier=sDansFileEntrée(Port)
_nb_octet_lu est un entier=0
_buffer est un buffer
TANTQUE _nb_octet_dispo>0
_buffer+=sLit(Port,_nb_octet_dispo)
_nb_octet_lu+=_nb_octet_dispo
_nb_octet_dispo=sDansFileEntrée(Port)
FIN
Info(_nb_octet_lu)
Info(BufferVersHexa(_buffer))
à tester déjà si votre trame est correcte..
connaissez vous le protocole de votre balance ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
940 messages
Popularité : +66 (68 votes) |
|
Posté le 23 octobre 2019 - 16:55 |
enfin c'est à peaufiner, en gérant le retour de sLit() si il a pu écrire correctement les données |
| |
| |
| | | |
|
| | |
| |
Posté le 29 octobre 2019 - 18:01 |
Le 23/10/2019 à 14:55, Christophe a écrit :
enfin c'est à peaufiner, en gérant le retour de sLit() si il a pu écrire
correctement les données
Bonjour Christophe
je répond tardivement car j’étais en déplacement pendant quelques jours.
Je pense que ma demande n'est pas correcte
Caract(0x01)+Caract(0x10)+Caract(0x39)+Caract(0x39)+Caract(0x4D)+Caract(0x35)+Caract(0x3c)+Caract(0x0D)+Caract(0x0A)
Je vais demandé de l'aide a Precia
Merci pour votre aide précieuse
--
R ELEX |
| |
| |
| | | |
|
| | |
| |
Posté le 12 février 2020 - 15:50 |
Bonjour à tous,
Nous venons de passer pas mal de temps à essayer de faire fonctionner notre soft avec le même protocole de la balance Precia Molen i20 que celui utilisé par Expeditor Inet : Protocole "POSTE" dans la configuration de la balance. Expeditor Inet doit disparaitre et le client nous demande de faire fonctionner notre soft en parallèle d'Expeditor le temps de tout bien roder.
Donc info importante récupérée au bureau d'étude de Privas, maison mère de Precia Molen : le protocole "POSTE", contrairement à "ESCLAVE A" par exemple, est un protocole que La Poste a commandé spécifiquement pour elle. Donc elle n'est pas documentée dans les docs i20.
Pour une demande de pesée, le message à envoyer à la balance est, en hexa : 02 64 03
Quant au retour de la la balance, il est aussi différent du protocole ESCLAVE A : "<2> <0>000270%<3>"
270 étant le poids en gramme, et % l'unité de mesure, à remplacer par gramme ou kilo ou je ne sais quoi d'autre dans votre programme.
Bref, sans ces infos, le protocole POSTE est inutilisable. S'il vous faut la doc complète transmise par le bureau d'étude, demandez là moi dans ce post. |
| |
| |
| | | |
|
| | |
| |
Posté le 05 mai 2020 - 18:01 |
Bonjour Jeff,
Il semble que je sois dans la même situation que vous, à savoir remplacer Expeditor Inet  .
Je serais très intéressé par la documentation dont vous parlez afin de faire avancer notre projet.
Vous remerciant par avance.
Cdlt
Alain |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|