RS-485 from Windows

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,

This might not be the right group to ask, but I suspect there must be people
outhere who have dealt with this:

I have an RS485 board in my Win2K machine, which uses the RTS signal to
change the direction of the RS-485 tranceiver.

With EscapeCommFunction() I can change the state of the RTS signal but, as I
espected, this function almost works immediately. Thus, the following code
will not work:

EscapeCommFunction(hComm,SETRTS);
WriteFile(hComm,.......)
EscapeCommFunction(hComm,CLSRTS);

The last call to EscapeCommFunction() will put the RS485 transceiver in
receive before the data is really sent. Is there a way for an application to
check wether all data has been sent, from within windows?

This must be a known issue since the existense of for instance PC's talking
Modbus....

Meindert



Re: RS-485 from Windows
Quoted text here. Click to load it
people
I
to
talking


Hmm. Probably a silly idea, but could you calculate the time
required to send out all+1 characters and setup a timer event
that turns off the RTS ?

--
Thanks,
Frank Bemelman
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 from Windows
I believe ClearCommError has a field that tells you how many chars are
pending.

Quoted text here. Click to load it
as
code
application



Re: RS-485 from Windows
Quoted text here. Click to load it

After browsing the net, this is not a silly idea. I think it is the only way
to go on application level. The only trick is to get an idea of the timing
error of this method. My experience with timer events in windows are not
that optimistic....
Thanks for the suggestion.

Meindert



Re: RS-485 from Windows

Quoted text here. Click to load it

Check out the fRtsControl field of the DCB structure.  It can be set to
RTS_CONTROL_TOGGLE.

Regards,
Karl Olsen




Re: RS-485 from Windows
Thanks for all the tips. It seems that setting RTS_CONTROL_TOGGLE in the
fRtsControl field of the DCB structure is the way to go.

Meindert



Re: RS-485 from Windows
Quoted text here. Click to load it

There appears to be a problem with this, under certain versions
of windows:

http://support.microsoft.com/support/kb/articles/Q140/0/30.asp


--
Thanks,
Frank Bemelman
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 from Windows
Quoted text here. Click to load it

I know, but I'm using Win2K.

Meindert



Re: RS-485 from Windows
Hi,
When you call a GetCommState(), the PC reset (or set, I don't remember) the
control signals...

Yvan

*********************************
            YBDesign
  http://www.ybdesign.fr
*********************************



3f01337c$ snipped-for-privacy@news.nb.nu...
Quoted text here. Click to load it
people
I
to
talking



Re: RS-485 from Windows

Quoted text here. Click to load it

If you've got to control the RTS line manually from your app,
you got ripped. The only practical way to handle this is to let
hardware do it.  Any decent RS-485 will take care of it for you.

Quoted text here. Click to load it

Perhaps.  The people I've talked to who tried to wait for the
last stop bit to get onto the wire then toggle RTS in SW never
got it to work reliably [I've only tried it under Linux, and I
gave up and bought a board that did it in hardware].

Quoted text here. Click to load it

Yes.  You use a proper RS-485 board.

--
Grant Edwards                   grante             Yow!  ... or were you
                                  at               driving the PONTIAC that
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 from Windows
Quoted text here. Click to load it

I disagree. Software is arguably the correct way to do this. How would
hardware know my requirements?

I've seen RS232-485 converters with auto-RTS, but I've yet to see a PCI/ISA
board with it. It's assumed that software has control. (That's not to say
they don't exist; just never seen one.)

Quoted text here. Click to load it

I've had no problem with "getting it to work reliably" under software
control - albeit mainly in an embedded environment where I had good control
of timers. Windows is indeed another animal - but I've had such cards
working reliably under DOS using my listen workaround (see other post).

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: RS-485 from Windows
Quoted text here. Click to load it

I've been doing RS-485 for 15+ years, and the requirement has
always been the same: assert RTS (enable line drivers) when
transmitting.

Quoted text here. Click to load it

The boards are using crappy UARTs.  Among others, Exar 16850
UARTs do auto-RTS.  Any decent multi-port serial board should
handle auto-RTS in hardware.

Quoted text here. Click to load it

In an embedded environment it's simple.  Under Window/Unix,
it's not.

Quoted text here. Click to load it

The echo feature may not be available -- some boards will do
it, some won't.

--
Grant Edwards                   grante             Yow!  I know how to get the
                                  at               hostesses released! Give
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 from Windows
Quoted text here. Click to load it

The last board I used had a pair of transceivers (75176-type) to allow fdx.
Non-typical, I guess.

Quoted text here. Click to load it

Sure. (Of course a single 75176 [hdx] can also be left receiver-enabled
while tx'ing.)

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: RS-485 from Windows
Quoted text here. Click to load it

This can be a minor problem if you want really fast turnaround between
transmit and receive.   Most modern UARTS and OS's use the FIFOs
on the UART chip.  If the FIFO is active, the UART does not provide
an interrupt unless:  

1.  the FIFO has reached the trigger level,
2.  Several character times have gone by with no new input chararcter.

The latter condition means that your OS may not know of the end of
the transmit until several character times after the last character
is transmitted (and received ) by the sender.  As a practical matter
it means that you may have to wait for several character times before
responding to an incoming message.

Mark Borgerson


Re: RS-485 from Windows
Quoted text here. Click to load it
I tried the trick with RTS_CONTROL_TOGGLE in the fRTSControl field of the
DCB and it works perfectly.

Meindert



Re: RS-485 from Windows
Quoted text here. Click to load it

Not necessarily. If you purchase a card where the manufacturer tied the RE\
and the DE signals together to save an IO pin on the UART, you cannot send
and receive at the same time.

Meindert



Re: RS-485 from Windows

Quoted text here. Click to load it

Paul is 100% correct.

With our 16550 UART we ended up programming a PIC onboard the unit
with a one-shot timer that would fire another serial interrupt past
the time when the FIFO was empty, and then hacked up the linux serial
interrupt and code to trigger and understand this oneshot.

If you're doing your own board design and are using RTS control, try
and use a more capable UART.
--
Alex Pavloff - remove BLAH to email
Software Engineer, Eason Technology

Re: RS-485 from Windows

Quoted text here. Click to load it

[...]

Quoted text here. Click to load it

Been there, done similar things (e.g. add an extra byte to the
end of the message and shut off RTS when _that_ tx interrupt
happens), and wasted a lot of hours...

Quoted text here. Click to load it

Definitely.

--
Grant Edwards                   grante             Yow!  .. I'm IMAGINING a
                                  at               sensuous GIRAFFE, CAVORTING
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 from Windows


Quoted text here. Click to load it

For those who are not familiar with this technique, this should work
quite well with protocols with distinct frame delimiters, such as SOH,
STX and ETX, but it definitely does not work with protocols like
Modbus.

When the extra character is 0xFF (for no or odd parity) or 0xFE (for
even parity), only the start bit (and the first data bit with 0xFE) is
in the "0" state and the line then goes to the "1" state, where it
will remain through the (parity and) stop bits and continuing as the
idle condition.

If the disabling of the transmitter is delayed by one (or two) bit
times, the transmitter has actively driven the line to the "1" state
(and charged the line capacitance) when the transmitter goes
tri-state. However, if the transmitter is switched off during the
start bit ("0"), the passive pull-up resistors have to pull the line
to the idle ("1") state.

Paul
  

Re: RS-485 from Windows

Quoted text here. Click to load it

If you use blocking mode, this doesn't happen (the WriteFile doesn't exit
until all the data has been sent.  You don't have any real way of knowing
when the RTS will be cleared in this case, only that it is cleared after
transmit.  Since I had control of both ends, the protocol specified 16
character times of dead space before a response, and I never ran into a
conflict.  If you don't have control of the other end, though, this might
not work.

Blocking mode is sometimes frowned upon in Windows programming (it eats CPU
cycles).  I put the code in a thread, so my program didn't have any real
problems though.  The extra CPU cycles were worth it for the much
simplified programming.  If you try that route, you'll want to look into
the SetCommTimeouts to make sure the functions unblock and return in the
case of non-response.  


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000
Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Site Timeline