id10t_error
Lifetime Supporting Member
Hey Guys, I hope all is well; quick Question,
Background:
We have a Siemens OEM Vendor package we were trying to communicate to, and the processor contains a 6ES7241-1CH32-0XB0 (CM1241 RS-485 communication module) connected to our Prosoft PLX31-EIP-MBS4 (Modbus to EtherNet/IP class1 connection).
We're polling addresses 40001 through 40019 without any communication errors and addresses 40001-40015 contain the correct 16-bit process values from the Prosoft diagnostic window, no problems, and verifiable on the vendors HMI.
However, the endianness seems different in my bit-packed address 40016 through 40019 for boolean statuses and alarms. It's like the lower Byte needs to be swapped with the upper Byte when comparing the current process conditions on the Vendor's HMI to both the Prosoft diagnostic data map and our Vendor's address list in excel.
Question:
If we change the Byte-swapping inside the Prosoft module configuration for just the boolean packed addresses 40016-40019, the Prosoft module throws errors; however, the information seems correct after using an SWBP with REVERSE in studio 5000 to a new tag from our Prosoft Class1 Connection.
What could cause the Vendor's address map to contradict what I see in my Prosoft module other than the list is wrong? Does the CM1241 do something non-standard to the data? I would expect to swap bytes in the whole address range and not just a subset of the bit-packed address.
Let me know your thoughts,
Thanks,
Background:
We have a Siemens OEM Vendor package we were trying to communicate to, and the processor contains a 6ES7241-1CH32-0XB0 (CM1241 RS-485 communication module) connected to our Prosoft PLX31-EIP-MBS4 (Modbus to EtherNet/IP class1 connection).
We're polling addresses 40001 through 40019 without any communication errors and addresses 40001-40015 contain the correct 16-bit process values from the Prosoft diagnostic window, no problems, and verifiable on the vendors HMI.
However, the endianness seems different in my bit-packed address 40016 through 40019 for boolean statuses and alarms. It's like the lower Byte needs to be swapped with the upper Byte when comparing the current process conditions on the Vendor's HMI to both the Prosoft diagnostic data map and our Vendor's address list in excel.
Question:
If we change the Byte-swapping inside the Prosoft module configuration for just the boolean packed addresses 40016-40019, the Prosoft module throws errors; however, the information seems correct after using an SWBP with REVERSE in studio 5000 to a new tag from our Prosoft Class1 Connection.
What could cause the Vendor's address map to contradict what I see in my Prosoft module other than the list is wrong? Does the CM1241 do something non-standard to the data? I would expect to swap bytes in the whole address range and not just a subset of the bit-packed address.
Let me know your thoughts,
Thanks,