Author Topic: OUTCOM issue ?  (Read 2008 times)

acxysty

  • Newbie
  • Posts: 30
  • I'm a llama!
    • View Profile
OUTCOM issue ?
« 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

garysdickinson

  • Expert Member
  • Posts: 464
  • Old PLC Coder
    • View Profile
Re:OUTCOM issue ?
« Reply #1 on: November 22, 2016, 02:46:56 PM »
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
    « Last Edit: November 22, 2016, 05:22:56 PM by garysdickinson »

    acxysty

    • Newbie
    • Posts: 30
    • I'm a llama!
      • View Profile
    Re:OUTCOM issue ?
    « Reply #2 on: November 23, 2016, 06:40:59 AM »
    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

    acxysty

    • Newbie
    • Posts: 30
    • I'm a llama!
      • View Profile
    Re:OUTCOM issue ?
    « Reply #3 on: November 23, 2016, 07:35:18 AM »
    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 ?

    garysdickinson

    • Expert Member
    • Posts: 464
    • Old PLC Coder
      • View Profile
    Re:OUTCOM issue ?
    « Reply #4 on: November 23, 2016, 09:56:25 AM »
    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

    support

    • Global Moderator
    • Hero Member
    • *****
    • Posts: 3119
      • View Profile
      • Internet Programmable PLCs
    Re:OUTCOM issue ?
    « Reply #5 on: November 23, 2016, 10:06:50 AM »
    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.
    Email: support@triplc.com
    Tel: 1-877-TRI-PLCS

    acxysty

    • Newbie
    • Posts: 30
    • I'm a llama!
      • View Profile
    Re:OUTCOM issue ?
    « Reply #6 on: December 14, 2016, 07:30:37 AM »
    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


    support

    • Global Moderator
    • Hero Member
    • *****
    • Posts: 3119
      • View Profile
      • Internet Programmable PLCs
    Re:OUTCOM issue ?
    « Reply #7 on: December 15, 2016, 09:46:17 AM »
    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.


    « Last Edit: December 15, 2016, 09:56:12 AM by support »
    Email: support@triplc.com
    Tel: 1-877-TRI-PLCS