What are the hexadecimal values of DestInt for the three scenarios? The values are either 0x436E_3372 or 0x3372_436E for the first case, 0x436E_0EC8 or 0x0EC8_436E for the second case, and 0x436D_AD46 or 0xAD46_436D for the third case. Is this information accurate, or would you like to see additional examples?
Are you indicating that when you mention HEX1, you are actually talking about the value stored in .ReadData[360], and when you mention HEX2, you are referring to .ReadData[361]? In a broader sense, can we say that HEX1 represents .ReadData[N], while HEX2 represents .ReadData[N+1]? This is because HEX1 typically corresponds to the value stored at index N in the data, while HEX2 corresponds to the value stored at index N+1.
The ProSoft Swap Code will yield one of two outcomes: None or Swap Words. The code syntax should be as follows: CPS(MBTCP_1.DATA.ReadData[360], test_real, 1). It is unnecessary to duplicate the data in an intermediate DINT, as the word exchange will be executed within the ProSoft configuration.
Here is the breakdown of how the example INTs convert to floats using Python's struct module:
- (0x3372, 0x436e) converts to 238.20095825195312
- (0x0ec8, 0x436e) converts to 238.0577392578125
- (0xad46, 0x436d) converts to 237.67684936523438
When analyzing the conversion of 0x436E0EC8, we can break it down as follows:
- 0x86 = 134
- 134 - 127 = 7
- 2^2 = 128
- 128 + 1*64 = 192
- 192 + 1*32 = 224
- 224 + 0*16 = 224
- 224 + 1*8 = 232
- 232 + 1*4 = 236
- 236 + 1*2 = 238
- 238 + 0*1 = 238
- 238 + 0*0.5 = 238
- 238 + 0*0.25 = 238
- 238 + 0*0.125 = 238
- 238 + 0*0.0625 = 238
- 238 + 1*0.03125 = 238.03125
- Continuing this pattern eventually leads to 238.0577392578125
It is important to note the conversion process shown above when working with hexadecimal values in Python.
In a recent project involving a Power meter that supports Modbus TCP with each signal as a 32-bit Float, it was discovered that the standard used is Little Endian - Byte swap contrary to popular belief. Despite extensive searches on forums, confusion on how to effectively convert the data persisted. To tackle the issue, a code snippet was used for converting to 32-bit. However, the correct byte order for Modbus TCP data transmission should be B1, B0, B3, B2 for DWORDs or REALs. It is essential to follow this order to ensure seamless communication with a Modicon PLC. Many companies overlooked this aspect and sent bytes arbitrarily, leading to compatibility issues. In essence, words should be sent big endian with the most significant byte first, while DWORDs follow a different order with the least significant word first. Modbus TCP implementation can be tricky, but with proper guidance and understanding, challenges can be overcome.
- 08-07-2024
- Peter Nachtwey
When encountering issues with Modbus implementations, it may seem overwhelming, but in reality, there are only a few key variations to consider. The focus should be on the byte order within the 16-bit Modbus Registers. For example, when reading the data array from the power meter using the ProSoft module, attention should be given to the word order within each pair of words holding the bits of a single REAL value.
To resolve any discrepancies, the ProSoft Swap Code configuration parameter offers two options: 0 for No Change and 1 for Word Swap. It is recommended to experiment with both options to determine which yields a reasonable REAL value. In rare cases where neither option works, exploring Word and Byte Swap (2) or Byte Swap (3) may be necessary.
Furthermore, analyzing the starting register for the floats, whether it is even or odd, can also provide insight into resolving the issue. Seeking guidance from @frandESS for the Modbus register map or a link to it for the specific power meter in question can also be beneficial.
Explore the wonders of modbus communications with the help of this website. For converting hex values online, visit https://www.scadacore.com/tools/programming-calculators/online-hex-converter/. Your hex value of 3372436E (bytes ABCD) translates to 5.64... e-8 and will be displayed as 238.2 when word swapped (CDAB).
I received fantastic feedback from you, and DrBitBoy - suggesting an upgrade to ProfBitBoy. Your insights on Hex1 / Hex2 were spot on. Your solution proposal, utilizing CPS(MBTCP_1.DATA.ReadData[360], test_real, 1), worked flawlessly without requiring manipulation from Prosoft. Your wealth of knowledge and dedication is truly appreciated. I plan to spend this weekend deepening my understanding of this topic, which I have been avoiding for years.
Currently experiencing speed issues with Prosoft, but I view this as a tuning challenge for another day. Running one L36ER with 28 Modbus Clients (20 on AOI and 8 on Prosoft module), I am able to achieve a scan time of 400mS for 10 transactions with no overlaps. Each Modbus client requires 60 INT's to read and a few Write commands as well. Additionally, I have 2pcs of 1734AENT Remote IO with 6 modules each, along with an Energy Management System that includes load shedding within the factory, control of geothermal wells, a 1MWh battery with 1MW battery inverter, an 800kWp Bifacial PV system, and Peakshaving and Frequency Support for the Norwegian grid.
I am grateful for all the valuable comments shared in this discussion thread.
frandESS confirmed that the assumptions about Hex1 and Hex2 are correct, representing different parts of the REAL* data. The CPS(MBTCP_1.DATA.ReadData[360], test_real, 1) function worked without requiring any manipulation from Prosoft. The Hex2 Word, 0x43xy, represents the "high" Word of the REAL, while Hex1 represents the "low" and first Word. It is assumed that LSByte-first also means LSWord-first, and both the Power Meter and L36ER PLC use an LSByte-first CPU. This is why the ProSoft Swap Code value remains unchanged.
frandESS expressed intent to further educate themselves on the topic over the weekend, acknowledging the importance of understanding the complexities of binary data processing. As Jouni Rynö mentioned, it's just zeros and ones, but it can be intricate. Starting with resources like the IEEE 754 standard for single-precision floating-point format can be helpful. Keep in mind terms like "endian," "byte," "integer," "16-bit," "signed," and "unsigned" are just ways to categorize and interpret data. The key is in understanding how the bits are organized and represented.
Hello! This topic recently arose in our discussions. One valuable resource is a website that displays the hexadecimal representation of Floating Point or REAL numbers, which can be found at https://baseconvert.com/ieee-754-floating-point. It's worth noting that every PLC I've encountered utilizes the IEEE-754 format for Floats or REALs. Additionally, I have created a CoDeSys simulation to illustrate the consequences of misinterpreting the REAL value. For a visual demonstration, check out this video of me walking through the simulation:
Drbitboy suggested ignoring most of @Peter Nachtwey's assertions about the challenges of Modbus implementation. Having encountered the complexities of multiple Modbus devices on a RS-485 line operating with differing Modbus RTU and Modbus TCP protocols, the process of byte and word manipulation for each device can be cumbersome. Adhering to standards is crucial, yet frustration arises when manufacturers, like Modicon, fail to define 32 bit transfers, leading to confusion among customers.
Encountering similar issues with Profibus, discrepancies in byte and word order between devices can cause communication challenges. Ensuring compliance with standards, such as Profibus certification, is necessary to mitigate issues arising from varying interpretations of specifications.
Furthermore, participation in industry events like "plug fests" for Ethernet/IP and Profinet allows vendors to test device compatibility, exposing discrepancies in interpretations of specifications. As a result, specifications are often updated to address inconsistencies and close loopholes.
While Drbitboy may not have experienced the chaos firsthand, he highlights the need for an enhanced Modbus protocol, suggesting the incorporation of Modbus/UDP for efficient I/O data transfer alongside Modbus/TCP.
- 08-07-2024
- Peter Nachtwey
Peter Nachtwey mentioned that he has experienced chaos that Drbitboy hasn't witnessed. However, as someone who has been immersed in technology for my entire life and is nearly the same age as Peter, I beg to differ. Perhaps my perspective on chaos differs because of my understanding of its origins.
In my career in the broadcast industry, I dealt with controlling video and audio switchers and routers from serial to TCP/IP connections. Protocol documents were always labeled with a "DRAFT" watermark. I developed diagnostic tools and troubleshooted to ensure tasks were completed successfully.
The issue of byte order is a persistent challenge that may never be fully resolved in our lifetimes. For instance, I created a server using RA, DEC, and magnitude data to swiftly retrieve stars from a vast catalog using SQLite's R*tree feature. The server discerns whether a client request uses LSB or MSB and responds accordingly, eliminating the need for clients to adjust.
While I agree that adhering to intelligent and accurate standards would simplify our lives, the reality is different. I prioritize problem-solving over argumentation and prefer a pragmatic approach to getting tasks accomplished.
Regarding Modbus, the finite number of potential binary errors in its implementation makes troubleshooting manageable. Creating and implementing diagnostics for pinpointing issues is straightforward, making the problem appear trivial in the grand scheme of things.
On a lighter note, the mix-up with Horner and Profibus byte order, as humorously shared by Peter, is quite entertaining. It's amusing to think that someone could overlook such a basic detail and then publicize it. Peter's anecdotes never fail to bring a smile to my face. He should definitely consider documenting and sharing more of these anecdotes.
It can be frustrating when a vendor implements MODBUS TCP differently across various product lines. I encountered this issue while working on a project that involved integrating switch gear information into a DCS system. The Medium voltage gear and low voltage gear had distinct requirements - one needed a word swap while the other needed a byte swap. Despite successfully testing on a low voltage model in our shop, discrepancies between the two were discovered during on-site commissioning. The vendor in question was EATON, who cited the use of two different voltages, development groups, and standards as the reason for the discrepancy.
Two Phoenix Contact products from different divisions were utilizing Modbus RTU, but with conflicting implementations. Each device had the polarity of its RS-485 driver lines labelled differently, one using A/B and the other using +/-.
In response to a comment, I, a seasoned tech professional, question the validity of certain tech-related issues due to my extensive experience in the field. While some may struggle with chaos, my understanding of its origins allows me to navigate such challenges effortlessly. Dealing with a large number of motion controllers prompts the consideration of byte order, a recurring "problem" that seems eternal. As a retiree, I prioritize upholding standards rather than compromising, ensuring a seamless experience for all clients. Embracing a practical perspective, I prioritize efficiency over being right, focusing on completing tasks successfully. Despite the complexity of tech issues like Modbus, I find solace in the fact that they are manageable and resolvable with the right approach. On a humorous note, I recall amusing anecdotes regarding byte ordering discrepancies in tech systems, highlighting the importance of attention to detail. As a tech professional, I emphasize the significance of certification and collaboration to avoid compatibility issues and streamline processes effectively. Control.com forums often feature discussions on common tech challenges like Modbus protocols, reflecting the need for improved understanding and best practices in the industry.
- 08-07-2024
- Peter Nachtwey
Driver vendors can learn from Red Lion and incorporate byte swap and word swap capabilities at both the driver and device levels. The differences in endianness between a SLC and Micrologix can cause issues when communicating with floats using DF1 protocol. It's crucial for vendors to address these compatibility concerns to ensure seamless data exchange.
Peter Nachtwey posed a question about dealing with a large number of motion controllers in the field. The issue arises when you have over 10,000 motion controllers in operation. However, this may not directly affect the original poster. It is important to consider how many of these 10,000+ units are actually experiencing problems. Typically, the issue only affects customers who have purchased non-standard devices to connect to the controllers. As a service provider, the focus should be on solving the problem for the customer. If you are in the business of selling motion controllers, it is advisable to recommend higher quality devices to avoid compatibility issues. In the scenario where a single customer has purchased 10,000+ motion controllers for a specific site, one solution could be to acquire or develop protocol converters, albeit at a premium cost to the customer.