Forum Home › Forums › Runtime Bugs › Communicator Bugs › Same configuration different command frame on Windows and Linux
- This topic has 9 replies, 2 voices, and was last updated 2 years, 9 months ago by zzz.
-
AuthorPosts
-
June 21, 2021 at 7:41 am #9113zzzParticipant
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 : 67453201Frame 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.June 21, 2021 at 7:57 am #9114zzzParticipantLinux 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
}}}June 21, 2021 at 8:51 am #9116MikhailModeratorHello,
Please copy the appropriate logs from Communicator.
June 21, 2021 at 10:29 am #9118zzzParticipantI 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;
}
}}}}
June 21, 2021 at 10:37 am #9119zzzParticipante.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!June 21, 2021 at 11:41 am #9120zzzParticipant{{{
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.
June 22, 2021 at 3:34 pm #9132MikhailModeratorDevice 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?
June 23, 2021 at 3:17 am #9138zzzParticipantNope. 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. ButBecause 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 onCommand
right pane will change as the user select different element data type, e.g. if4byte 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 2 years, 9 months ago by zzz.
June 23, 2021 at 12:07 pm #9148MikhailModeratorI 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.June 24, 2021 at 1:01 am #9152zzzParticipantKind 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…
-
AuthorPosts
- You must be logged in to reply to this topic.