Bonjour à tous,
Depuis quelque temps je dois paramétrer un dispositif via une page web déporté.
Lors que je transmet la trame qui est composé comme : <ID00><L1><PA><MA><Le>Data Cs <E>
Les caractères Ascii < et > sont transformé en Hexa : 0x3C et 0x3E respectivement.
J'ai essayé de changer les caractères par leur équivalent Mnémonique c'est à dire < et > mais ça ne change rien.
En attente d'un coup de main pour régler cette histoire qui me prend la tête
Amicalement,
Payrro.
re-bonjour ,
Pour pallier le souci précédent j'envoie toute ma trame en hexa mais maintenant avec wireshark j'ai découvert que la page web envoie tout un tas d'information html supplémentaire dont je n'ai pas besoin et qui fait rebooter mon dispositif
Message envoyé:
Cliquez pour afficher
Je cherche comment enlever le surplus d'information pour ne laisser que la trame
Merci
P.S : De plus dans mon premier message, les caractères sont transformés en %3c et %3c. Erreur de ma part
Dernière modification par Payrro ; 08/10/2014 à 09h54.
Bonjour
Comme on a absolument aucune idée de votre infra technique, il va être plus que délicat de vous fournir une réponse.
Bonjour,
je travaille sur un module tcp/ip CSE-H53 configurer en serveur TCP mon but est de créer une page web sur laquelle je rentre un message qui est traité et mis dans une trame le tout envoyé en Ethernet au module qui le retransmet en RS232 a un PC ou je récupère la trame via Hercule.
sinon que voulez vous dire par infra technique ?
Un peu plus que ce que vous avez mis au dessus .Envoyé par Payrro
Ce n'est pas très clair quand même :
Où est composé la page ?
Quel composant sert la requête ?
Dans la mesure où vous envoyez des infos, pourquoi une requête en GET en lieu et place d'un requête en POST ?
Faire un petit schéma car votre infrastructure n'est pas limpide (même si on ne comprends pas trop le pourquoi de ces conversions RS232/802.3, il doit y avoir une raison).
Dernière modification par Bluedeep ; 10/10/2014 à 09h22.
Le choix de la méthode GET c'est pour vérifier le contenue de la trame que j'envoie .
On y comprend rien.
Faites un schéma SVP !!!!
Ma page web est composé via l'éditeur bloc note et est sauvegarder sur mon pc
Pour le Shcéma j'espère que sa vous aidera :
Pour le composants qui sert la requête je ne sais pas dsl.
Donc sur le pc portable je lance ma page web qui envoie la trame au module puis je récupère le tout sur le pc fixe a l'aide du logiciel Hercule
Je ne comprend toujours pas le pourquoi d'une page web dans cette sombre affaire.
Par ailleurs la page web est obtenu depuis quoi .... ???
Et vous parler d'une requête en GET pour verifier la trame; requête qui part d'où vers où ?
Comment est lancée la requête en POST pour envoyer la trame ?
Si le module attend un contenu dans une trame TCP pourquoi encapsuler dans du HTTP + HTML ?
Faire un schéma des séquences de flux, merci.
Dernière modification par Bluedeep ; 10/10/2014 à 10h29.
Sommairement, ma tâche est de :
Paramétrer un afficheur LED () via une page Web Déporté obtenu depuis un fichier texte où est écrit le code de la page en HTML.
Le module relie l'afficheur a internet
L'information obtenue sur la page web est envoyé par méthode GET au module qui la re-transfert au panneau
Je vous ai joints mon code en HTML de ma page
Pièce jointe supprimée
Dernière modification par JPL ; 10/10/2014 à 12h35.
Comme je vous l'ai écrit plus haut GET n'est pas la bonne requête pour envoyer une page. C'est la méthode POST qui doit être utilisée.
Je comprends mieux le coup du module RS232/Ethernet, mais je suis très étonné que le panneau attende de l'HTML; vous êtes sur de cela ? c'est plus que surprenant.
Et vous ne répondez pas aux autres questions : comment est envoyée la page ? (on envoie jamais une page depuis un client, elle est envoyée depuis un serveur sur une requête GET et sur une requête POST on envoie son contenu : bref, il y a encore un truc pas clair dans vos explications).
Par ailleurs, je ne comprends pas ce que vous voulez dire par "page web déportée"; pour moi c'est un OINI (objet informatique non identifié).
Dernière modification par Bluedeep ; 10/10/2014 à 11h10.
Payrro, utilise plutôt la balise Code (# dans la barre d'outils du mode avancé). Voici ce que cela donne :
Ou, avec la balise HTML (<> dans la barre d'outils) :Code:<html> <head> <title>parametrer votre afficheur </title> </head> <body> <br> <br> <center> <h2>Tapez votre message:</h1> </center> <br> <form method="GET" action="192.168.1.2"> <center> <input type="text" name="trame"><input type="submit"> </center> </Form> </body> </html>
Code HTML:<html> <head> <title>parametrer votre afficheur </title> </head> <body> <br> <br> <center> <h2>Tapez votre message:</h1> </center> <br> <form method="GET" action="192.168.1.2"> <center> <input type="text" name="trame"><input type="submit"> </center> </Form> </body> </html>
Dernière modification par JPL ; 10/10/2014 à 12h33.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Bonjour,
Je rejoins Bluedeep, je ne connais pas d'afficheur qui attendent des données en HTML, tout ceux que j'ai pu rencontrer attente de l'ASCII.
D'ailleurs dans votre premier message vous encapsulez des commandes en ASCII dans du HTML.
Après leur codage dépend du fabricant, certains se programmaient aussi à l'age du minitel et là le HTML n'était pas né.
Je pense que vous buttez sur le HTML qui n'est requis, semble-t-il, que pour la saisie utilisateur, ce qui pourrait se faire bien mieux dans beaucoup d'autre langages plus évolués.
Après pour transférer les infos, et je me permet de corriger Bluedeep, le TCP n'assure que le transport et régit les trames différemment de l'UDP par exemple, ce sont des protocoles de transfert de données qui font partie de la suite TCP/IP.
Jetez un oeil sur TCP/IP Wikipédia sur internet vous comprendrez mieux que le HTML n'a rien à voir là dedans, et aussi au passage qui fait quoi.
Dans votre schéma votre boitier TCP/IP est donc une interface de protocoles entre du TCP/IP et du RS232, toujours rien à voir avec ce qui est dans la trame ni par quoi ou comment elle est codée.
Par contre j'abonde dans le sens de Bluedeep, vos explications sont plus que nébuleuses, où est l'afficheur ?
Si l'afficheur possède une interface TCP/IP pourquoi diable le brancher sur un port série RS232 sur un autre PC ? Qui doit pas être tout jeune le PC d'ailleurs pour avoir encore du RS232 derrière
Pour info le RS232 est aussi un protocole de transfert de données en "série" (trames donc aussi) par opposition au transfert dit "parallèle" des imprimantes hors d'age maintenant.
Donc inutile de vous dire que le RS232 à part dans certains milieux industriels, ou sur du matos qui n'évolue plus.... Ca fait belle lurette que j'ai bazardé les prises et socket RS232 que j'avais en stock
Je pense donc que vous devriez songer à utiliser un autre langage plus approprié pour la saisie et pour traiter la couche "application" (cf. Wikipédia TCP/IP).
Vous avez de très bon langages en open source, en Java par exemple.
Et qui sont portables de plus sur tout un tas de périphériques et d'OS comme un téléphone, un Iphone, une tablette, un PC.
Périphériques qui se connectent aussi à internet et véhiculent leur infos en protocole TCP/IP mais par Wifi pas par câble pour certains.
Voilà, maintenant faisant partie de ces "vieux" programmeurs, je ne peux que vous conseiller de faire avant toute choses un organigramme de programmation.
Le problème le plus fréquent c'est que maintenant avec les langages évolués Wysiwyg (What you see, what you get), les jeunes programmeurs (je ne parle toujours pas de l'age !) ne prennent même plus le temps d'apprendre les bases le B. A. BA.
Je fais de la programmation depuis 1977, à une époque où c'était le Basic pour commencer et après lorsqu'on voulait attaquer plus pointu c'était de l'assembleur.
Ce que j'ai toujours su (Ok je n'applique plus ce précepte maintenant, mais bon j'ai l'expérience) c'est qu'à la base un beau dessin sous forme d'organigramme va vous permettre le debug de votre programme, de le maintenir si besoin après, de le faire évoluer, de l'adapter à un nouvel environnement. Bref c'est pas neutre.
Donc un beau croquis avec des rectangles pour les commandes, des losanges pour les conditions, les liens fléchés qui explique le cheminement du programme, etc.
Après moi je dis ça à vous de voir, mais je sais aussi que même pour du HTML ça marche du feu de dieu pour identifier ses propres sottises et se rappeler ce qu'on à fait après
Bon courage.
Et désolé de vous avoir repris sur le TCP/IP Bluedeep, ce n'était que pour éclairer les choses
Merci de ne pas m'en vouloir.
Cordiales salutations et respect à vous.
donc si j'ai bien compris tu envoies une requete à un serveur web sur ton autre pc , tu récuperes les parametres de l'url que tu as transmis pour pouvoir faire ton traitement
si tu trouves que tu envoies trop de données protocolaires ; change de protocole ...
