Comment réduire un trop long delai d'activation de ligne RTS sur port RS232 ?

[denis.crete]

Bonjour,
 
Je voudrais faire communiquer un PC avec un périphérique utilisant la liaison RS485: j'ai un convertisseur bidirectionnel RS232/RS485 contrôlé par la ligne RTS du port série RS232.
Je suis donc obligé d'utiliser la ligne RTS pour contrôler le flux de données sur le port série.
Le problème auquel je fais face, au vu des signaux sur la ligne RTS et la ligne RS485 avec un oscilloscope, vient d'un trop long retard entre le moment où le PC a fini d'envoyer sa commande et l'activation de la ligne RTS pour "écouter" la réponse du périphérique : la voie associée à la ligne RS485 montre le train d'impulsion de la commande du PC vers le périphérique avec une amplitude raisonnable (~10V) suivi par un intervalle (un silence) de 4ms; ensuite les 2 premières ms du train d'impulsion de la réponse du périphérique au PC avec une amplitude fortement réduite (< 1V) suivi par la partie restante du train d'impulsion de la réponse du périphérique au PC avec une grande amplitude (~10V).

A l'oscilloscope, la ligne RTS n'est activée qu'après  6 ms (c'est-à-dire 4ms + 2ms = quand le signal sur la ligne RS485 devient correct), indiquant que le périphérique et le convertisseur fonctionnent correctement, mais le PC commande la ligne RTS trop lentement après l'envoi de la commande.

J'utilise LabView 6.1. Quand j'ai essayé LabView 7.1, je ne pouvais pas voir le signal RTS du tout (pourquoi ?). Dans les deux cas j'ai dû configurer les propriétés de VISA utilisant "un noeud de Propriété", (la fonction "VISA config" n'étant pas efficace pour ce paramètre - ni pour la bascule d'activation du Caractère de Terminaison) spécifiant l'utilisation du protocole de contrôle de flux RTS/CTS.

Dans le VI "afap-rw" ci-dessous (à l'intérieur du polygone), la fonction "VISA Read" est déjà appelée immédiatement après la fonction "VISA write" pour réduire le retard autant que possible. Il ne semble pas être possible de réduire ce délai par une meilleure programmation.

J'ai aussi essayé de positionner l'état de la ligne RTS en utilisant le "noeud de propriétés" du Modem (tandis que le contrôle de flux a été configuré sur "Aucun" dans "VISA Config " ET dans le contrôle de flux du "Noeud de propriétés", cf. "Manual RTS" à l'intérieur de l'ellipse) mais alors le retard atteint environ 50 ms!!

Je comprends que je pourrais développer une DLL pour activer la ligne RTS sitôt que le dernier caractère de la commande ait été envoyé et lire la réponse avant de retourner au système, mais je n'ai pas l'expérience du développement de DLL.

Je pourrais aussi considérer

- commander la ligne RTS avec un circuit (monostable redéclenchable déclenché par le train d'impulsions venant du PC) pour qu'il active la ligne RTS 2 ... 3 ms après la dernière impulsion sur la ligne 3. C'est bon marché, mais ce n'est pas une solution élégante!

- acheter la dernière version de LabView (pourvu que cela puisse résoudre mon problème)

- acheter une carte d'interface PCI avec un port de RS485 (compatible avec LabView 6.1 ou 7.1)



Y a-t-il une meilleure solution, utilisant de préférence LabView 6.1 (éventuellement 7.1) et la ligne RTS ?

Merci beaucoup pour votre aide

[denis.crete]

Hello,
First let me apologize for having published my question intended for the french community to the international forum: I took the liberty to translate the title and here is the translation of the text:

I would like my PC to communicate with a peripheral using RS485 link: I have an RS232 to RS485 bidirectionnal converter controlled by the RTS line of RS232 serial port.  So that I need to activate the RTS line of the RS232 port to receive the message from the peripheral.
The problem I am facing, as seen on the RTS line and RS485 line with a scope, is a too long delay between the moment the PC has finished sending its command and the activation of the RTS line for "listening to" the answer of the peripheral: in greater detail  = the trace associated with the RS485 line shows the pulse train of the command from the PC to the peripheral with a reasonable amplitude (~10V) followed by a blank of about 4ms; then the first 2ms of the pulse train of the answer from the peripheral to the PC with a strongly reduced amplitude (<1V) followed by the remaining part of the pulse train of the answer from the peripheral to the PC with a large amplitude (~10V).
On the scope, the RTS line is activated after 6 ms (i.e. 4ms + 2ms = when the signal on  the RS485 line becomes correct), indicating that the peripheral and the converter are both working fine, but the PC does not drive the RTS line after sending the command.
I am using LabView 6.1. When I tried LabView 7.1, I could not see the RTS signal at all (why?). In both cases I had to configure the VISA properties using a "Property node", (the VISA config function not being effective for this parameter - and neither for the Termination Character enable flag) using the RTS/CTS protocol.  
In the VI in "afap-rw.gif" (enclosed in a polygonal zone), the VISA Read function is already called right after the VISA Write function in order to reduce the delay as much as possible. It does not seem to be possible to reduce this latency by proper construction of the program.
I have also tried "asserting" and "unasserting" the RTS line in the Modem properties (while the flux control was set to None in the VISA Config AND in the "Node properties/serial port/Flux control", cf. "Manual.gif" inside the ellipse) but then the delay reaches about 50 ms!!
I understand that I could develop a DLL to assert the RTS line as soon as possible after the last character of the command has been sent, and return the answer prior to returning to the system, but I am not familiar with this, not being a developer.
I might also consider  
- commanding the RTS line with a circuit (retriggerable monostable triggered by the train of pulses coming from the PC so that it will activate the RTS line 2...3 ms after the last trigger pulse on line 3. This is something cheap I could do but would sure look ugly!
- buying the latest version of LabView (if it is guaranteed to solve the problem !...)
- buying a PCI interface board with an RS485 port (if it works properly with LabView 6.1 or 7.1)
 
Is there a better solution, preferably using LabView 6.1 or 7.1 and the RTS line?  
Thank you very much for your help
Denis