M
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
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