Same configuration different command frame on Windows and Linux

Forum Home Forums Runtime Bugs Communicator Bugs Same configuration different command frame on Windows and Linux

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #9113
    zzz
    Participant

    Session use ModbusTCP

    (Command Setting)
    Element Type: float/4bytes
    Element Count: 2 ( on windows, automatically set to 2 if set to 1, which I suppose means WORD count, not 2 float element. )
    Byte Order empty

    (Templeate Setting)
    Zero Based
    Decimal
    Byte Order
    2byte :
    4byte : 2301
    8byte : 67453201

    Frame Sent on Windws
    {{{
    03 7b 00 00 00 0B 0E 10 02 0E 00 02 04 9F 6F 46 9A
    }}}

    Frame sent on Linux Mono,
    {{{
    07 08 00 00 00 0F 0E 10 02 0E 00 02 08 12 EB 47 2F 00 00 00 00
    }}}

    There are trailing zeros padding additional bytes.
    It seems only Modbus commands have this problem. Haven’t noticed it on Modbus retrived values.

    #9114
    zzz
    Participant

    Linux Mono, same data, injected with generator
    {{{
    00 79 00 00 00 0F 0E 10 02 0E 00 02 08 9F 6F 46 9A 00 00 00 00
    }}}

    #9116
    Mikhail
    Moderator

    Hello,

    Please copy the appropriate logs from Communicator.

    #9118
    zzz
    Participant

    I am on developer branch, Github is taking ages to open, please see source, there is byte count is doubled, not sure why.

    I am not sure how such problem is not detected in months. I guess, this should be recent change. The Linux instance is setup just yesterday. Windows was long time ago.

    ModbusCmd.cs L149
    {{{
    // формирование PDU для команды WriteMultipleCoils или WriteMultipleRegisters
    int dataLength = TableType == TableType.Coils ?
    ((ElemCnt % 8 == 0) ? ElemCnt / 8 : ElemCnt / 8 + 1) :
    ElemCnt * ModbusUtils.GetDataLength(ElemType);
    }}}

    ModbusUtils.cs
    {{{

    /// <summary>
    /// Gets the length required to store element data depending on the element type.
    /// </summary>
    public static int GetDataLength(ElemType elemType)
    {
    return elemType == ElemType.Bool ? 1 : GetQuantity(elemType) * 2;
    }

    public static int GetQuantity(ElemType elemType)
    {
    switch (elemType)
    {
    case ElemType.ULong:
    case ElemType.Long:
    case ElemType.Double:
    return 4;
    case ElemType.UInt:
    case ElemType.Int:
    case ElemType.Float:
    return 2;
    default: // Undefined, Bool
    return 1;
    }
    }

    }}}

    #9119
    zzz
    Participant

    e.g.

    Send (17): 0B 1A 00 00 00 0B 0E 10 02 0E 00 01 04 46 B8 2E AB
    Receive (7/7): 0B 1A 00 00 00 03 0E
    Receive (2/2): 90 03
    Device error: [03] ILLEGAL DATA VALUE!

    #9120
    zzz
    Participant

    {{{

    ReqPDU = new byte[6 + dataLength];
    ReqPDU[0] = FuncCode;
    ReqPDU[1] = (byte)(Address / 256);
    ReqPDU[2] = (byte)(Address % 256);
    ReqPDU[3] = (byte)(ElemCnt / 256);
    ReqPDU[4] = (byte)(ElemCnt % 256);
    ReqPDU[5] = (byte)dataLength;
    }}}

    I always thought by ElemCnt you mean Element Word Count.
    Since In the Device Template Editor, changing the data type, the “ElementCount” field changes, 2 for float, 4 for double, which is number of words.
    And in above code ElemCnt is set to reg (WORD) qty in PDU ,
    then GetDataLength() shoud reture a constant 2 for non bool types.

    But if you really mean Elemnt Count, then ReqPDU[3:4] should not be set to ElemCnt.

    ElementCount, DataLength etc are very confusing on first glance, initially I guess they are in WORD unit, but it takes more crunching to understand. Maybe it can be reworded.

    #9132
    Mikhail
    Moderator

    Device error: [03] ILLEGAL DATA VALUE!

    It’s a valid answer returned by the controller. You can check it by this parser or other parsers.

    Did you write that requests are broken in case of using Linux?

    #9138
    zzz
    Participant

    Nope. Windows was using … maybe the last release not current relese or maybe even older. Linux is using lastest release, as this thread was started, on official site for Linux.
    I was also wondering if that what Linux fault. But

    Because the immigration was caused by a windows corp. security software updated that causes ramdom windows freeze (unacceptable for control pc), I pulled the latest dev branch code and compile the KpModbus module, copied it to Linux, it didn’t work. I copied it to Windows, RS on windows stopped working either.
    The frame hex code in log on both machine are identical – wrong data, different from previous Windows frame.

    Working Frame Sent on Windws

    
    03 7b 00 00 00 0B 0E 10 02 0E 00 02 04 9F 6F 46 9A
                                     || ||
                                  2WORD ||
                                        4bytes
    

    Wrong Frame sent on Linux

    
    00 79 00 00 00 0F 0E 10 02 0E 00 02 08 9F 6F 46 9A 00 00 00 00
                                     || ||
                                  2WORD ||
                                        8bytes?
    

    If I set element qty to 1, the trailling 0s are gone, the byte count become valid, but the register count will be 1, which should be 2 (1 float =2 WORD = 4Byte).

    As was explain in my last post, I am confused what ElemCount was supposed to mean here, ElementReigsterCount/WORDCount or ElementCount, thus I am not sure what’s the correct fix, so I just replace ModbusUtils.GetDataLength(ElemType) with 2. then it works, on both linux and windows, the generated request frame become
    {{{
    03 7b 00 00 00 0B 0E 10 02 0E 00 02 04 9F 6F 46 9A
    }}}

    If ElemCount was supposed to mean ElementCount, there is another issue, in the DeviceTemplate Editor, the Element Count field on Command right pane will change as the user select different element data type, e.g. if 4byte float was selected, Element Count will be automatically set to 2, which I supposed means 2 words/register per element, or how does the editor know I send 2 element instead of 1 or 3 Element ?

    • This reply was modified 11 months, 1 week ago by zzz.
    #9148
    Mikhail
    Moderator

    I don’t remember the details of the source code of the KpModbus driver.
    If you can provide an example of Rapid SCADA configuration that causes wrong Modbus data packets, we could consider them here.

    #9152
    zzz
    Participant

    Kind of emergency here, due to the system freeze issue. Maybe I can create a minimum setup to replicate the issue, after my system immegration work is done…

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.