COMM using half-duplex RS485

[PC Programmer]

How do you control the DTR line and keep it in time with the serial output?  Although I've used GetOutQLen() and tried to determine when the Q is empty in order to toggle DTR, it is inconsistent and doesn't seem to really track with the number of bytes in Q.

What is a solid approach to interfacing with an external '485 chip using a signal, such as DTR, to toggle between transmit and receive?

[Robert M]

Are you using VISA to control the serial communication?  Which half-duplex wiring mode are you using?  From NI-VISA's help for Default vs. Configured Communication Settings:

If the serial port is RS-485, then you can query and manipulate the attribute VI_ATTR_ASRL_WIRE_MODE, which designates the RS-485 wiring mode. This attribute can have the values VI_ASRL_WIRE4 (0, uses 4-wire mode), VI_ASRL_WIRE2_DTR_ECHO (1, uses 2-wire DTR mode controlled with echo), VI_ASRL_WIRE2_DTR_CTRL (2, uses 2-wire DTR mode controlled without echo), and VI_ASRL_WIRE2_AUTO (3, uses 2-wire auto mode controlled with TXRDY). This attribute is not supported for RS-232 ports. It is valid only on the platforms on which National Instruments supports RS-485 products.

If you have flow control set correctly, you can use VI_ATTR_ASRL_DTR_STATE to set the value of DTR.  NI-VISA's help on VI_ATTR_ASRL_DTR_STATE:

VI_ATTR_ASRL_DTR_STATE

Resource Classes

Serial INSTR

Attribute Information

Access Privilege Data Type Range Default

Read/Write

Global

 ViInt16

 VI_STATE_ASSERTED (1)

VI_STATE_UNASSERTED (0)

VI_STATE_UNKNOWN (–1)

 N/A

Description

VI_ATTR_ASRL_DTR_STATE shows the current state of the Data Terminal Ready (DTR) input signal.

When the VI_ATTR_ASRL_FLOW_CNTRL attribute is set to VI_ASRL_FLOW_DTR_DSR, this attribute is Read Only. Querying the value will return VI_STATE_UNKNOWN.

Hope this helps,

[PC Programmer]

I'm using a MAX487 connected to my Serial port.  Thus, I must have control over DTR.

I inhereted this app from someone and I don't know what control he used.  However, my question was how do I get DTR to track when the transmit buffer empties?

A friend of mine has suggested the erratic nature of this is due to inherent Windows latency.  Comment?

[Robert M]

Are you using your built-in serial port or a National Instruments serial board? 

GetOutQLen() returns how many bytes there are in the output queue, but even if the length is 0, there may still be data in the FIFO.  If you want to be sure that all data has been sent before toggling the DTR line, I would turn off your FIFO.  You can do this in Windows device manager. 

Also, instead of calling GetOutQLen(), you could simply call Flush(), which only returns after all data has been sent out of the output queue.

Hope this helps,

[RobertoBozzolo]

I take this occasion to clarify a doubt of mine

I shoulde be able to disable the output FIFO by setting to a negative value the Output Queue Size parameter in OpenComConfig, i.e. using OpenComConfig (1, "", 19200, 0, 8, 1, 512, -1);  Is this true or not?

Message Edited by Roberto Bozzolo on 10-06-2005 04:42 PM

[PC Programmer]

I have an EXTERNAL MAX487 chip, not an NI card.  So, it goes via PC serial port to MAX487 and on.

>Also, instead of calling GetOutQLen(), you could simply call Flush(), which only returns after all data has been sent out of the output queue.

Is this regardless of whether I'm using a NI board or not?

[PC Programmer]

I see a function called: FlushOutQ -- but it removes characters from the output queue rather than sending them to the port.

[RobertoBozzolo]

PC Programmer, have you tried using the ComSetEscape () function?

According to documentation, it should give you access to some pins of the  com port such as DTR and RTS signals.

[PC Programmer]

>have you tried using the ComSetEscape () function?

Yes, that is what I'm using to actually control the DTR signal and it does control it. HOwever, the problem is trying to time it with the serial out que. Programmatically, you turn it on, turn it off. The problem is that you never know exactly how long Windows will take to ship it all out. Similarly, using Delay() is equally unpredictable. It wanders around a considerable amount.

What I found is that using the Delay() minimum resolution of 0.0001 provides sufficient delay to send and force DTR low before my target responds. That was easy enough, but the difficulty is when my transmit string increases.

So, I simply added 300 mS for each 38.4K Baud byte to my delay and it seems to adapt well enough. 

There is a timing issue that puzzles me where I can see DTR assert and de-assert well before my 3 byte string goes out the port (a Windows thing, no doubt).  It eventually synch's up and runs OK for the most part.  Is there no hard control of these things?  No hardware level access available via CVI?

It isn't what I'd like, but it seems to work.

I was also puzzled about the reference to Flush().  I can't find that in any of the documentation for Ver 6.  What is there is FlushOutQ() and that removes all characters from the Q.  I can't see how this is any help.  Did I miss something?

[RobertoBozzolo]

Yes, documentation about FlushOutQueue is not clear: you don't know if this function actually forces write to the port or if it clears the outq before message is sent...

Other possibilities I can think of (maybe you have already tried all these...) are:

- InstallComCallback with LWRS_TXEMPTY in the event mask: this should fire an event when tx queue is empty. Don't know exactly how it interfaces with windows environment, though...

- OpenComCOnfig with -1 as Output Queue Size: this should bypass the output FIFO and let CVI write directly to the com port. This has solves some misterious problems I had with missing messages: maybe you can take advantage of this option too.