Internet PLC Forum
General => Technical support => Topic started by: acxysty on November 22, 2016, 09:02:17 AM
-
We have make a strange observation.
We are using the following program :
DM[141] = &H03 ' node address of slave
DM[142] = &H03 ' function 03
DM[143] = &H00
' upper 8 bit of address
DM[144] = &H01
' lower 8 bit of address
DM[145] = &H00
' upper 8 bit of count
DM[146] = &H01 ' lower 8 bit of count
DM[147] = &HD4
DM[148] = &H28
FOR I = 1 to 8 ' send out the MODBUS RTU command in binary
OUTCOMM 1, DM[140+I]
NEXT
DELAY(25)
' delay for a while to wait for response
FOR I = 1 to 8 ' get rest of response
DM[150+I] = INCOMM (1)
NEXT
We monitore the transmission with a network analyser and we observe that sometimes the latest byte transmitted is NOT 28 as it should be ! All the previous bytes are OK.
Any ideas where to look at ? Do we need to had a delay after every OUTCOM command ?
Regards
Thierry
-
Thiery,
I don't see anything in your code that has to do with the OUTCOMM statements that would result in the last byte of your Modbus RTU query getting messed up.
You didn't show me the initialization code for the serial port on the PLC. It is possible that you missed a very important step. If you implement your own communication protocol, you must disable the PLC from automatically responding to serial bus activity. This is code from one of my projects that act as a Modbus master:
SetBAUD MODBUSPort, 6 ' 38.4K Baud, 8 data bits, 1 stop bit, no parity for MODBUS, VFD
SetProtocol MODBUSPort, 10 ' Try to get PLC firmware to NOT mess with this serial port
[/color][/font]
The SetProtocol statement is very important. If you do not issue this statement, the PLC may "see" the response form the slave device and respond to it as if it were a Modbus query. This can result in the mixing of serial data from your Modbus RTU code with the PLC's builtin response to Modbus activity. Please verify that you have issues the proper SetProtocol statement.
In regards to your questions about OUTCOMM:
- Please remember that the OUTCOMM statement only places an 8-bit data value in a buffer. The actual data transmission is performed by system level firmware.
- All 8 of your OUTCOMM statements probably complete before the first byte of your Modbus RTU query even starts to be transmitted by the PLC.
- You do not need to add delays after the OUTCOMM statement. In fact you MUST NOT add delays. One of the requirements for MODBUS RTU is that the entire data frame must be transmitted without delays between characters. The delay between Modbus frames is spec'd at about 3.5 character times. At 9600 BAUD this would be about 3.5 ms. If you were to insert a delay of this magnitude then the Modbus device could interpret this delay (gap) as the end of the frame.
Your use of the DELAY(25) to allow for the Modbus query to be transmitted and a response to be returned is probably too short to work. If you are working at 9600 BAUD, it will take a minimum of 8 ms for the query to be transmitted and 8 ms for the response to be received. This leaves only 9 ms for the overhead of both the PLC system firmware to process both the messages going both ways and for the slave device to respond. I haven't found a commercial Modbus device that can respond in less than 20 ms. This makes the time to receive the full response frame more like 36 ms minimum.
I suggest that you start with something on the order of DELAY(100) to allow enough time for the PLC to transmit the query and to allow most typical Modbus devices to respond.
Best regards,
Gary D*ckinson
-
Dear Gary
Thank you for your long answer.
We did properly set the protocole to mode 10 in order to be sure that we do not interfer with existing MODBUS procedure. We increase the delay to 100 but still we have problems.
We use Docklight software as a viewer of the Rx/Tx frames. And it is clear that sometimes the latest bytes of the frame is not H28 has it should be. It can be any number ....
We alos work with micro-controller ( ST7 and ST8 ). Therefore we know how these components work.
But using the OUTCOM function, we have no way to undertand why the value is not the one we expect. Is it a problem of timing ?
Regards
Thierry
-
Doing tests with 2 nanos, we are wondering how quickly we can use the INCOM and OUTCOM fonctions one immediately after the other ? Is there any limitations or risk of doing.
Is there any way of having detailled information of how both functions works ?
-
Sorry that the long answer did not solve your problems.
Let me emphasis the short answer, "your usage of OUTCOOM and INCOMM are not the reason that the last byte of the Modbus frame is being corrupted".
It is nice that you understand ST7 and ST8 microprocessors. Have you connected a ST7/8 device to the RS485 bus? If so disconnect it.
Allow me to suggest that if you have anything connected to the RS-485 bus other that the PLC and your Dockviewer device that you remove them. If the data corruption of the last byte of the Modbus frame goes away, you now know where to focus your attention.
If your RS485 cabling is using less that 3 wires and the third wire is not connecting the PLC "-" ground to the signal ground of the USB<-->RS485 dongle used by your PLC for Dockviewer, then fix this oversight.
Gary D*ckinson
-
Do have have a terminal emulator software? The RealTerm software (free download) can be used together with the U-485 to see the data that flows on the RS485 bus. As per Gary's suggestion, remove all the other devices on the rS485 bus and then just use the OUTCOMM command to send data from your program and check what the terminal emulator software see to confirm if the wrong data byte actually comes from the PLC.
If without other devices attached and the OUTCOMM seem to work properly with the proper data output but the data get corrupted when the other devices are attached then someone is driving the RS485 bus when it is not supposed to and that could lead to corruption of the data from the PLC.
-
So, we have connected 2 Nano with RS485, without anything else.
We configured the master with no protocol, and the slave with RTU protocol.
the on-line monitoring and view variable is file attached.
The problem is concerning the last byte of the outcom frame , you can see it in the docklight view.
Master :
1st scan :
SETPROTOCOL 1,10
SETBAUD 1,&H13
REFRESH
RETURN
Every scan :
DM[1] = &H03 ' node address of slave
DM[2] = &H03 ' function 03
DM[3] = &H00 ' upper 8 bit of address
DM[4] = &H01 ' lower 8 bit of address
DM[5] = &H00 ' upper 8 bit of count
DM[6] = &H01 ' lower 8 bit of count
//X = CRC16 (DM[1],6) & &HFFFF ' compute the CRC16 of DM[1] to DM[6]
DM[7] = 212 //X / 256 ' upper 8 bit of CRC16
DM[8] = 40 // & &HFF ' lower 8 bit of CRC16
FOR I = 1 to 8 ' send out the MODBUS RTU command in binary
OUTCOMM 1, DM[0+I]
NEXT
DELAY(100) ' delay for a while to wait for response (30)
FOR I = 1 to 8 ' get rest of response
DM[10+I] = INCOMM (1)
NEXT
IF DM[1]=DM[11] and DM[2]=DM[12] and DM[13]=2 and DM[16]=193 and DM[17]=132
else
DM[20]=DM[20]+1
ENDIF
DM[21]=DM[21]+1
B=DM[14]*256 + DM[15]
DM[40]=B*66/1000
REFRESH
IF DM[14]<0 OR DM[15]<0 THEN
DM[22]=DM[22]+1
ELSE
DM[22]=0
ENDIF
IF DM[22]=1 THEN
DM[31]=DM[40]
DM[23]=DM[23]+1
ENDIF
IF DM[22]=2 THEN
DM[32]=DM[40]
DM[24]=DM[24]+1
ENDIF
IF DM[22]=3 tHEN
DM[33]=DM[40]
DM[25]=DM[25]+1
ENDIF
IF DM[22]=4 tHEN
DM[34]=DM[40]
DM[26]=DM[26]+1
ENDIF
IF DM[22]=5 THEN
SETIO OUT3
DM[35]=DM[40]
PAUSE
ENDIF
Slave :
SETPROTOCOL 1,1
SETBAUD 1,&H13
REFRESH
RETURN
-
From your outcomm pattern error it appears that when the error occured, the RS485 transmitter transmitter was switch off prematurely during the transmission of the last byte so the 2 MSB became a '1' when they were supposed to be zero.
Can you check the firmware version of the PLC that was involved (both masters and slaves)? Have you upgraded their firmware to the latest version? There were some changes in the firmware relating to RS485 transmitter timing in recent firmware fixes that aim to improve RS485 communication and a firmware upgrade may eliminate the problem. If you don't have the firmware upgrade link please write to support@triplc.com for more information.