Afficheur de caisse

"JKB"

En vrac :

As-tu essayé d'envoyer tes trames par un autre moyen ? ( par exemple un bout de code C qui tourne sur un autre PC + port RS232 )

As-tu comparé les signaux RS232 du soft d'origine (celui qui marche) avec les signaux de ton soft ? (j'ai vu des cas où la polarité est inversée !)

Sur certains afficheurs il faut nécéssairement respecter un délai entre les trames, et ce délai varie suivant la commande émise. Pas exemple il faut attendre tant de millisecondes aprés l'effacement de l'afficheur, etc ... si ces délais ne sont pas respectés ( T >= T_délai ) alors la commande suivante n'est pas du tout prise en compte.

Sinon, est-ce que cet afficheur n'affiche rien du tout (blank), ou est-ce qu'il affiche quelque chose, même si ce n'est pas ce qui est attendu ?

Le Sat, 6 Aug 2011 19:12:41 +0200, Jean-Christophe écrivait :

Impossible. J'ai dû bricoler l'analyseur parce que la liaison n'est ni une DB9 ni une DB25 (encore moins une 37, mais pour en avoir vu, il faut être un dinosaure avec des écailles... ;-) ). Je suis obligé de tester sur cette machine.

C'est difficile à faire. Le soft d'origine balance un tas de commandes les unes après les autres et je n'ai aucun moyen d'enregistrer les trames. Je ne touche pas la partie électronique donc je n'ai pas de problème de polarité.

Tiens, c'est intéressant, ça... Je vais creuser un peu...

Il affiche quelque chose, mais pas du tout ce qui est attendu...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

A ta place j'essaierais d'enregistrer sur mon analyseur RS232 une séquence telle qu'envoyée à l'écran par le logiciel de caisse d'origine, et de répéter la même séquence en Java Il y a probablement une différence, soit dans la séquence d'affichage elle-même, soit dans une séquence d'initialisation un peu avant. Enregistre également le timing : il y a peut-être un espacement minimum à respecter quelque part ou au contraire un délai maximum à ne pas dépasser (time-out)

Ah, désolé, je n'avais pas vu une réponse au-dessus de la mienne. Ma proposition est inadéquate.

"DF" a écrit dans le message de news:

4e3d87c5$0$30760$ snipped-for-privacy@reader.news.orange.fr...

"JKB"

La liaison RS232 est-elle uniquement dans le sens PC -> afficheur, ou est-ce que l'afficheur retourne des trames vers le PC ? Pour certains matériels, après envoi d'une commande le PC doit attendre un code de retour qui confirme l'exécution de ladite commande. Si le code de retour est un NACK ou s'il n'arrive pas avant un timeout, alors il faut réitérer la commande ... un peu comme un Minitel !

J'ose à peine te demander si, en cas de RTS, CTS, DTR, est-ce qu'ils sont correctement gérés ( timming, etc ) Bon, je n'ai rien dit :o)

T'ayant lu ici et ailleurs, je doute que tu n'aies pas les ressources ni l'astuce nécéssaires pour brancher un PC sur cet afficheur, mais bon.

Même sans aller jusqu'à analyser le contenu des trames, tu pourrais au moins estimer le délai entre elles ... Il y a bien longtemps (...) j'ai enregistré un dialogue sériel entre deux matériels avec un PC à deux ports RS232, en branchant son Rx COM1 et son Rx COM2 sur les Tx et Rx de la com à enregistrer. ( les trames étaient horodatées, stockées en RAM puis sauvées sur disque ) Quand on peut s'en passer on s'en passe, mais s'il faut en arriver là, ca aide.

L'as-tu constaté par une mesure sur les signaux eux-mêmes ? J'avoue que ce serait vicieux, mais une telle situation n'est pas impossible.

Tu nous tiens au courant quand tu auras du nouveau ? C'est bien le genre de truc qui peut resservir.

Tu es *sûr* du format 9600,N,8,1 ?

Le Sat, 6 Aug 2011 20:33:10 +0200, Jean-Christophe écrivait :

D'après la spec, ça ne fonctionne que dans un sens. L'afficheur ne renvoie rien.

Non, je ne peux pas. Il est sur un PC de caisse, solidaire de la chose, et je ne peux pas l'utiliser ailleurs à moins de casser un bout de plastique. Il faudrait que je fasse une photo pour montrer le montage. En tout état de cause, je ne peux faire de manipulations simples sur l'afficheur lui-même. J'ai truandé en utilisant un autre port COM pour analyser les trames.

Je ne vois pas comment ça pourrait arriver. La seule différence entre les deux est une différence soft et non hard.

Ça pourra même resservir à Toshiba... Sont infichus de faire fonctionner leur propre matos !

Oui. Ça se fixe par des cavaliers. Mais j'ai aussi essayé les autres. Le seul qui reçoit quelque chose, c'est le 9600,8,N,1.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB a ecrit

bonsoir Il y a un "truc" que je ne saisi pas (ou pas bien) ? ;o) Si tu arrive à connecter un analyseur rs232 c'est donc bien que tu accede à la ligne TX (ou RX selon que tu considere l'equipement) ?

Qu'est ce qui t'empeche là de connecter en derivation un pc portable en RS232 avec un simple soft UART pour logger et/ou injecter des data (eventuellement à la à la mano) , quitte a jongler dans un premier temps avec les lignes RX/TX de la RS232 (vu du PC portable).

L'affichage meme si ce n'est pas ce que tu attend change selon les envois ?

Rvl

JKB a tapoté du bout de ses petites papattes :

T'as pas un PC ?

--
LeLapin

Le 06/08/2011 18:39, JKB a écrit :

Bonsoir,

face à un problème apparemment insoluble, il faut se dire qu'il y a forcément une raison pour laquelle ça ne marche pas, donc un pb qq part.

j'ai l'impression que quelque chose te déroute, il faut donc revenir aux bases.

si ton afficheur ne fct pas correctement, c'est que tu ne lui envoies pas les bonnes informations, tout simplement.

tu dis que tu envoies les bonnes trames via le soft, que tu l'as vérifié avec un analyseur, donc je conclus que le pb ne vient pas de là.

question : as tu regardé *toutes* les trames transmises ?

je penserai que le soft d'origine envoie une (ou des?) séquence d'initialisation que tu n'as pas reproduit.

as tu lancé ton soft après avoir fait tourner le soft d'origine, sans faire de raz ni de coupure ?

jj

"JKB"

Donc, sur la com RS232, seul le Tx du PC vers l'afficheur est connecté (?) Si non, avec le soft d'origine et Rx du PC déconnecté, ca marche toujours ?

Ok, je vois un peu mieux le set-up.

Oui, c'est la question que j'allais te poser. Donc tu es libre de faire tourner sur ce même PC depuis ce même port un soft de test (qui ne soit pas en Java) pour tester une séquence simple, du genre : { clear }, delay(100 ms), { display "hallo JKB" }

En soft pur, sur un PC, on peut trés bien piloter le chip d'interface RS232 en bas niveau de facon à lui faire faire ce qu'on veut. Je ne sais plus où j'ai vu une RS232 de PC avec les polarités inversées, mais je l'ai vu. ( je ne dis pas que c'est le cas pour cet afficheur, j'expose juste une piste )

Peut-être parce-que dans ce cas précis, ils n'en ont rien à tirer de sonnant et trébuchant.

Ok.

Le truc le plus probable qui me reste à l'esprit est un défaut de respect des timmings entre trames. J'ai eu ce cas il y a 2 mois sur un LCD 2x16 caractères, mon soft merdait complètement alors qu'il respectait les specs : le seul ajout d'un délai de quelques dizaines de ms entre l'émission des commandes a suffi pour que ca marche nickel. (ca fait toujours plaisir de perdre du temps sur ce genre de truc) Mais ces subtilités sont spécifiés dans la doc ... (qu'on a pas toujours le loisir de lire de A à Z)

Il est récent, cet afficheur, ou c'est un dinosaure ?

Le Sat, 06 Aug 2011 21:04:08 +0200, rvlegran écrivait :

Non, je configure le programme pour qu'il crache sur un autre port COM sur lequel j'ai un simple 6850 qui récupère les données. Je ne peux toucher au port _réel_ qui est interne.

Non. Pour un envoi, j'obtiens toujours la même chose.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le Sat, 06 Aug 2011 23:07:40 +0200, jj écrivait :

Les premières. Pour l'initialisation et l'affichage des premiers caractères. Le PC de caisse parle en continu à l'afficheur. La piste la plus intéressante me semble être cette histoire de timing que je vais essayer de vérifier cet après-midi. Par ailleurs, mes trames ont été validées par le service technique de Toshiba.

Peut-être, mais dans ce cas, cette séquence est inconnue de Toshiba et de sa doc. Je répète que j'arrive à effacer l'écran (première commande) et que les autres commandes font n'importe quoi. Donc le timing me semble une très bonne piste.

Oui, sans plus de succès. De toute façon, l'afficheur se réinitialise automatiquement après une coupure de courant dans un état connu qui affiche les caractères allemands. En toute hypothèse, je dois pouvoir écrire quelque chose en envoyant juste des caractères et je n'arrive qu'à envoyer _un_ seul caractère.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le Sun, 7 Aug 2011 01:39:06 +0200, Jean-Christophe écrivait :

Je ne peux pas tester la chose sauf à détruire le cordon ou le connecteur spécifique.

Je vais faire ça. Je vais même rajouter un délai _entre_ les octets, des fois que le truc soit cadencé avec un quartz en silex taillé et que son buffer de réception soit ridicule.

Crois-moi, je l'ai lue, la doc, et plusieurs fois même... Tout est spécifié et jamais on ne parle de délai entre les trames.

Il est récent.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

"JKB"

En principe la taille du buffer de réception doit être au moins égale au nombres de caractères de l'afficheur plus quelques octets pour un header genre 0x1B 0x5B etc. Pour le délai supplémentaire entre octets, je suis moins sûr : cela risque de désynchroniser sa détection de fin de trame.

Ok.

Celui que j'ai cité en exemple est récent lui aussi, colonne de droite de la befehlssatz pour les timmings :

De mémoire, les délais que j'ai du implémenter étaient bien plus élevés que 1,64 ms : de 20 à plus de 100 ms surtout pour les séquences d'init, qui doivent être bien séparées entre elles dans le temps. ( et pas envoyées trop tôt après la mise sous tension du display )

JKB a ecrit

A moins d'un board completement encapsulé sous resine (encore que même là ... ;o) il est quand meme assez rare de ne pas pouvoir se piquer à l'aiguille sur une pinoche ou piste.

Tu duplique ou tu fais une simple redirection par soft vers une autre interface, de ce que tu pense etre la totalité des trames emises à destination du module afficheur. ?

selon la methode employée, il peut y avoir de la latence et/ou du respect de timing mal vu.

Ce que tu essaie d'envoyer avec ton appli (java) tu le fais directement vers le port de l'afficheur (et là ça merde) , ou tu injecte par duplication du port com accessible vers le port com de l'afficheur ?

Instinctivement là avec les mix de soft et hard, mais sans plus de convictions avec les infos parcellaires, il y aurait du pull-down (ou up) mal brélé que je ne serais pas surpris.

J'ai du mal m'exprimer : Meme si ce qui est affiché n'est pas ce qu tu attend, est ce que l'affichage "change/differe" selon les trames envoyées par ton soft ?

Est ce que les caracteres affichés peuvent etre interpretés selon le datasheet de l'afficheur ? je pense là à un probleme de "table langue" mal initialisée, voir peut etre un probleme de MSB/LSB du au soft d'injection.

Le Sun, 07 Aug 2011 14:20:00 +0200, rvlegran écrivait :

Crois-moi, le connecteur est fait de telle sorte que tu ne peux même pas coller un gripe-fil.

Je configure le soft différemment. À la place de COM4, je lui demande de cracher sur COM1.

Directement vers l'afficheur. Mais la gestion du COM4 ne semble pas en cause puisque le même bout de code arrive à causer à l'imprimante avec grosso-modo le même protocole (sauf qu'elle est sur COM1).

Et là, ça me fout la trouille parce que rien n'est accessible. Le capot du bestiau est soudé et la carte-mère de toute façon minimaliste (c'est un C7 avec un windows pro embedded).

Oui. Mais pour une trame donnée, j'obtiens toujours la même chose sur l'afficheur.

Non.

Ça cause en octet. Ça ne serait pas pervers au point d'inverser l'ordre des bits ?

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB a ecrit

ça c'est plutot bon signe

Peut etre pas l'ordre des bits, peut etre simplement la commande en logique.

la logique serie TTL est pseudo inverse de la logique RS232. Là d'instinct je pondrais un soft minimaliste qui injecterais pour affichage les 256 valeurs possibles d'un octet, avec un delta de transmission de l'ordre de la demi seconde. start avec un chrono en main et stop à l'apparition d'un caractere reconnaissable (genre A---Z 0----9). ça permet de se reperer et de se positionner sur une table à ski ;o) et déjà de voir si la convention n'est pas inversée.

Rvl

"JKB"

Peux-tu espionner les trames de la sortie RS232 du soft d'origine en redirigeant son COM(x) vers un autre COM(y) accessible au scope ?

Le Sun, 07 Aug 2011 16:32:50 +0200, rvlegran écrivait :

Je viens d'essayer de renverser les bits sans succès, de faire une négation de la chose... Même motif, même punition.

Tiens, pas bête du tout, ça. Je m'en vais l'essayer...

Merci du tuyau,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr