RS232 - RS485 converters

M

Thread Starter

Mario de Sousa

Here goes one more question:

I am using an RS232-RS485/422 converter that relies on the RTS line of the RS232 side to control the high impedance state of the line drivers on the RS485/422 side.

On the other hand, the RS485/422 -> RS232 converter is always on, so whatever shows up on the RS485/422 side will always get transfered to
the RS232 side. Since RS485 has the send and receive lines connected to each other (half-duplex), when using RS485 the PC will read back
whatever it writes to the RS232 port.

Is this common in RS232-RS485 converters? If true, then we have to take this into account and throw away the first frame we read back after
sending a modbus query. That first frame will be the query we have just sent out!

I have already coded the above in such a way that it will work for both RS422 and RS485 transparently, but it assumes that we can detect the frame boundaries correctly.

What happens is that, when reading the serial port from a normal process, we cannot be assured of detecting those 3.5 character intervals, so we have to figure out another way of detecting the frame boundaries. The only efficient method I can think of is to figure out the size of the frame we are receiving by interpreting the first bytes
of the frame. This will work to some extent, but has the following problems:
1) Aborted frames, with the 1.5 character boundaries, will wreack havoc on our mechanism, and we will miss possibly correct frames being
transmitted after an aborted frame.
2) We do not know the size of every modbus frame, such as the frames for functions 9, 10, 13, 14, etc...
3) It is not possible to distiguish a query from a response frame just by analysing the header, and these may have different sizes!

On a single master bus (i.e. us!), 2) is not much of a problem as we won't be sending any function 9, 10, 13, 14 etc... queries, so we
shouldn't be getting those replies eiter.
We can work around 3) as this only raises two distinct possibilities, and we can figure out which one is correct by working with the CRC.
Number 1) is still a problem. The only other way I can think of detecting frame boundaries in this situation is to figure out possible frame boundaries that satisfy the message format, and check the CRC.
Computing the CRC is rather CPU intensive, and in an aborted frame situation we would have to do many calculations, and would therefore be
highly in-efficient. On the other hand, if everything is correct, we will only be calculating the CRC once, so we won't have many problems.

What I would like to know is:
- Would it make sense to go to the trouble of coding all this?
- Should we follow the appraoch of havng a so-so implementation on the user level, and have a good implementation as a device driver?
- Should we simply go for the so-so implementation at the user level and hope for the best?

The so-so implementation would not support aborted frames.

Cheers,

Mario.

P.S. Sorry for rambling on, but just the fact of having to explain all this helps me in getting my own ideas more organised!

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> Is this common in RS232-RS485 converters? If true, then we have to take
> this into account and throw away the first frame we read back after
> sending a modbus query. That first frame will be the query we have just
> sent out!

It is common, but not universal. I use converters without this "feature", personally.

Instead of ignoring the first query, why not read it in as normal and ignore it if it is identical to the query you just sent out?

This "line echo" can be useful too -- if you send a query and it is garbled, then two people tried to talk on the line at the same time. You can use this as a kind of collision detection, but you have to be careful of line lengths or you may not see collisions.

> What happens is that, when reading the serial port from a normal
> process, we cannot be assured of detecting those 3.5 character
> intervals, so we have to figure out another way of detecting the frame
> boundaries. The only efficient method I can think of is to figure out
> the size of the frame we are receiving by interpreting the first bytes
> of the frame. This will work to some extent, but has the following
> problems:
> 1) Aborted frames, with the 1.5 character boundaries, will wreack havoc
> on our mechanism, and we will miss possibly correct frames being
> transmitted after an aborted frame.
> 2) We do not know the size of every modbus frame, such as the frames
> for functions 9, 10, 13, 14, etc...
> 3) It is not possible to distiguish a query from a response frame just
> by analysing the header, and these may have different sizes!

I work with the received frame size in my applications. To eliminate the "aborted frame" problem I have a timer which will abort a frame detection if that frame is not completed within x bit-times. Obviously this doesn't work for everything but it works pretty good in my applications.

Regards,
Andrew

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Andrew Kohlsmith wrote:
>
> > Is this common in RS232-RS485 converters? If true, then we have to take
> > this into account and throw away the first frame we read back after
> > sending a modbus query. That first frame will be the query we have just
> > sent out!
>
> It is common, but not universal. I use converters without this "feature",
> personally.
>
> Instead of ignoring the first query, why not read it in as normal and ignore
> it if it is identical to the query you just sent out?
>

Yes, that's exactly what I am doing... ;-)

(...)
>
> I work with the received frame size in my applications. To eliminate the
> "aborted frame" problem I have a timer which will abort a frame detection if
> that frame is not completed within x bit-times. Obviously this doesn't work
> for everything but it works pretty good in my applications.
>

It seems you use the 3.5 character interval to detect frame boundaries?

Unfortunately we cannot rely on that interval on our application. The process doing the reading is one of many processes sharing the CPU.

It is highly likely that while the bytes are coming in through the RS232 port, the process is not running. When the process get's to run it
is simply reading the cached bytes. What can happen is that it might read an aborted frame, followed by a correct frame, but will not be able
to distiguish where the aborted frame ended and the correct one started. We are reading from a cache by now, so the 3.5 character delay is not
present anymore!

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
T

Thomas B. O'Hanlan

Commercial Break:

Please check out Sealevel Systems' line of converters @ www.sealevel.com. Like the companies' RS-485 boards, the converters feature "auto enable", alleviating having to toggle RTS. In addition, echo can be disabled with a switch postion. Line termination and pullup/pulldown resistors are selectable as well. Sealevel has isolated and non-isolated, and is finishing up a din rail monted converter. Thank you for listening.....

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi Mario,

Please check out "www.rs485.com":http://www.rs485.com or "www.rs485.com/pasc24t.html":http://www.rs485.com/pasc24t.html for "auto Tx enable" converters (RTS not required). The ASC24T RS-232<=>RS-485 converter is reasonably priced, has LED indicators, a removable terminal strip, termination/pullup/pulldown resistors are jumper selectable, and many additional features. This unit will operate at data rates up to 115.2Kbps(no comm settings required). Several models are available including galvanic isolation up to 3.0KV.

Thanks,

Ron
 
Top