고정 헤더 영역
상세 컨텐츠
본문
The RTU slave protocol can be implemented by adding the message parsing similar to ModbusRTUTransport.readResponse to the ModbusRTUTransport.readRequest method.Since there are no packet delimiters in RTU, the slave and master are supposed to read bytes and if the interval is more than 3.5 character times between characters assume the end of message and process accordingly. To avoid the timing to determine frame boundaries, I use message parsing to determine when the message is complete (see ModbusRTUTransport.getResponse.
Modbus Master Programs
This same approach will work in the slave.-John. Hie Dieter,I cannot use javax.realtime because all the APIs you can find use native librarys. I am developing a slave for a TINI 390 board. Of course it is possible to run native code on that system but I am not going to develop a new RT for it.My device will only react on a function code 04. I got a slave RTU working on the TINI with a jamod master on a PC.
I still have sometimes problems when I start a request, it hangs. After interrupting and restarting, it sometimes works.My question is, if I am checking the request message data bytes from the master if they fit my device ID and the function code, would it be enough to cope with the timing problem?I think the block flush on the slave side should work ok due to hardware buffers to not to corrupt the timing. What do you think? Would be nice if somebody could post any master RTU experiences.Nicholas. I have given this some thought and while I have not read the javax.realtime documentation, I think that to do time based message processing correctly we would need to move the RS-485 and character separation from Java to the rxtx JNI c library. There is JNI class derived from CommPort in rxtx that is intended for RS-485.
(Last I checked it was not yet complete though.) Moving the echo processing to the data link network layer would remove the data link layer processing currently done by ModbusRTUTransport. As I recall, the Modbus time specification is to consider the message complete if a delay of 1.5 characters occurs and wait at least 3.5 characters between messages. Nicholas,The echo is not there for RTU it is only there for RS-485 2 wire implementations which transmit and receive on the same lines. The best way to test your RTU slave is to get it working with standard RS-232 with echo turned off. Most RS-232 to RS-485 converters offer an option to turn echo off as well and in that case you want echo off. The only configuration which requires echo = true is for both ASCII and RTU protocols on a 2 wire RS-485 network with echo.The echo occurs when you transmit since the receive lines are tied to the transmit lines you receive everything you transmit. In peer-to-peer protocols you can use the received echo to verify that you did in fact transmit a valid message.
If a collision occurs because another peer was transmitting at the same time your protocol would need to back off and send again until you receive exactly what you sent. Since Modbus is a Master/Slave protocol, only the master can initiate a request. So you can assume the message echo is identical with what you sent and just ignore it as the RTU implementation in jamod does.When you get your slave working on the RS-232 without echo or echo = false if you need to implement on RS-485 you can either turn echo on or disable echo in your RS-232 to RS-485 converter. If you are using 2 wire RS-485 with echo you will need to set echo true in both master and slave unless there is a hardware option to disable the receiver when the transmitter is active.You definitely want to transmit the whole message as fast as you can then read the echo. Use block write as the ModbusRTUTransport.writeMessage does.
The reason is that if you are using a true time driven modbus slave you want to minimize the time between characters in a message. I believe that if you send a block of data followed by flush as the RTU master protocol does you will most likely satisfy a time based slave device. My reasoning is that the Master or slave owns a serial device when it has it open for Modbus RTU. The block write is transmitted to the serial device driver and data will be transmitted with little delay between characters since most devices are buffered in hardware. Also if you look at the output lines on an oscilloscope you will see close packing of the transmitted packet.As Dieter said there is no guarantee that you will meet the timing specs of the slave device you are transmitting to. Maybe someone who has used jamod RTU master protocol with industrial slaves can comment on its effectiveness.
C# Modbus Serial
Since I wrote the slave protocol I used to test jamod RTU master, I was able to get it to work with the CRC bytes in the wrong order. Someone else in this forum pointed out a while back that the bytes were swapped and that error was corrected.
Even though I copied the CRC code verbatim from the protocol spec I used to implement it I managed to get the bytes in the wrong order.-John.
