Hello, I am currently facing a challenge and would appreciate some assistance. I am working with an Allen Bradley Compact Logix PLC (5069-L320ER) and am utilizing a Prosoft Gateway (PLX31-EIP-MBS) to read Modbus RTU data from a gas monitor (RKI 410A). The gas monitor's manual specifies that the gas reading channel is in ASCII characters. Specifically, I am extracting 2 Oxygen registers from the RKI 410A and merging them into a DINT tag named O2_PCT within the PLC. Initially, when I set the style for the O2_PCT tag in the PLC to ASCII, I am able to read the accurate value of 20.9. Everything appears to be functioning correctly at this point. However, when attempting to transfer this value to the SCADA iFix database through the IGS driver, the decimal value of 842018361 is being displayed instead of 20.9. I am seeking guidance on how to convert the PLC value of 842018361 so that the SCADA system can interpret it as 20.9. After using an online Decimal to ASCII converter, it suggested that 50484657 represents 20.9, leaving me a bit perplexed. Any insights on this matter would be greatly appreciated. Thank you in advance.
Understanding the ASCII characters, bytes, and integer values is essential in various applications. For instance, the ASCII string "20.9" is made up of four characters: '2', '0', '.', and '9'. These characters correspond to specific decimal and hexadecimal values. When converted, the integer value 842018361 in decimal translates to 32302E39 in hexadecimal. By separating each byte, you can observe the hexadecimal representation of the string as 32 30 2E 39. Converting these bytes back to decimal yields 50 48 46 57. Regardless of the scenario, the byte-wise values remain the same, highlighting the importance of correctly interpreting them. If you're dealing with ASCII data like an O2_PCT tag, ensuring that the SCADA system interprets it as ASCII is crucial. Alternatively, you may need to convert ASCII values from devices like pressure sensors into readable formats like floating point numbers or scaled integers. A helpful resource on converting ASCII to decimal can be found in a discussion on plctalk.net, where a user details converting a pressure sensor's HEX ASCII output into a readable pressure value like 26 PSI. This conversion was achieved using SLC 500, showcasing the versatility and importance of understanding ASCII conversions in various engineering and data interpretation tasks.
Furthermore, as stated in the RKI Instruments Beacon 410A Operator's Manual, the gas reading in ASCII format is distributed across three registers. For instance, the gas reading is located in Registers 40011 to 40013, where six bytes (characters) house the channel gas reading in ASCII characters. For more information, you can refer to the manual here: https://www.instrumart.com/assets/RKI-Instruments-Beacon-410A-Manual.pdf.
According to the 410A's Operator's Manual, the gas reading in ASCII format is spread across 3 registers. The interpretation involves understanding the ASCII characters, corresponding bytes, and integer values. For example, the ASCII string "20.9" consists of the characters '2', '0', '.', and '9'. These characters correspond to specific decimal and hexadecimal values. When converted, the integer value 842018361 in decimal becomes 32302E39 in hexadecimal. By separating each byte and converting them back to decimal, you get 50, 48, 46, 57. This process remains consistent byte-wise regardless of interpretation methods. To force the interpretation of values as ASCII instead of integer, adjustments may need to be made in the SCADA system or on the PLC side. Utilizing ladder logic or custom tagging within the IGS driver can facilitate this conversion process. Explore more on this topic in the following link: Converting ASCII to Decimal.
Leeisfishing mentioned that the third register (40013) is identified as '%V' in ASCII format, which is unnecessary for SCADA purposes. Make sure that you are not encountering the common "off by 1" register addressing problem in Modbus. For more information on Modbus Register Numbering and how it varies among vendors, refer to this informative post on control.com. Referencing the 410A manual, the following two registers after the gas reading pertain to the units, specifically registers 40014 and 40015. These registers store the channel gas units in ASCII characters within 4 bytes. It is important to note that when reading three registers with included units, you could be accessing registers 40012 - 40014 (combining gas reading and units) instead of registers 40011 - 40013 (solely for gas reading). If the ProSoft gateway adopts 0-based Modbus register addressing, ensure to access holding registers 10 - 13 to correspond with the reference register numbers 40011 - 40013.
Did you check if you are encountering the common "off by 1" register addressing issue in Modbus protocol? Visit this informative post on Modbus Register Numbering to understand more about this recurring topic. Different Modbus vendors use varied numbering schemes in their documentation, so it's crucial to recognize and interpret them correctly. In the 410A manual, it is stated that the unit registers follow the gas reading registers. When reading three registers, you might be actually accessing registers 40012 - 40014 (gas reading and units), not 40011 - 40013 (gas reading only). If your ProSoft gateway uses 0-based Modbus register addressing, you should access holding registers 10 - 13, corresponding to register numbers 40011 - 40013. Keep in mind to be cautious of this issue, as it has been observed with other Prosoft gateways before.
It sounds like there's a type mismatch issue between the PLC and your SCADA system. When the PLC sends the ASCII number to the SCADA system it's being misinterpreted as an integer, which leads to a nonsensical value. It looks like you need to convert the DINT tag in the SCADA system to ASCII, just as you did in the PLC, to display 20.9 correctly. You might also try checking if your IGS driver is capable of handling ASCII characters. If not, it might be necessary to utilize some sort of conversion function at the SCADA level. Best of luck with your troubleshooting!
It sounds like you're dealing with an issue of data type conversion. It seems like the SCADA system is interpreting the PLC value as a double-precision floating-point number, which likely leads to the odd decimal value you're seeing. You might want to look into converting the ASCII value to a float in the PLC before sending to the SCADA system. The PLC should have built-in functionality for typecasting operations like this. The exact process might differ depending on the specifics of your setup, but it generally involves splitting the ASCII values into bytes, using them to construct the floating-point number, and then interpreting the result. Might take a bit of work, but this should allow the SCADA system to represent the values accurately.
It sounds like you're dealing with a little endian/big endian issue, possibly coupled with a character encoding mismatch. The 842018361 is likely the decimal (integer) equivalent of the four ASCII characters representing your O2 reading in hexadecimal format, but may suffer from byte-order misinterpretation. ASCII "20.9" corresponds to hex values of '32 30 2E 39', but when these hex values are combined and read as a single 32-bit little-endian integer, it corresponds to the 842018361. But SCADA systems might expect the data in a certain byte order or character encoding, and thus you are seeing the decimal integer instead of the floating point value. Maybe you could consider restructuring your bytes and converting the ASCII values back to a float in your PLC or SCADA system. It would be interesting to know how you are sending data to the SCADA system as well, as it might have impact on this issue.
Hey there, it sounds like you're having an issue because the SCADA system reads the ASCII value directly as decimal and isn't performing the necessary conversion to double precision floating point, which would give you your correct value of 20.9. In other words, the problem arises from data interpretation. Remember, ASCII representation and direct decimal numerical representation aren't the same. Try converting the DINT tag O2_PCT in PLC to an ascii string then transfer this ascii string to SCADA system. Depending on your SCADA system, you might have to write a script that decodes the ascii string back into double precision floating point number. It requires a bit more coding, but it allows the software to interpret the numbers correctly. Also, the decimal to ASCII converter reference isn't really going to help in your case because it sounds like you need conversion to Double precision floating point format, not ASCII. Hope this helps and good luck with your project, you're definitely on the right track!
It sounds like you're on the right track by reading the ASCII data correctly, but the issue might be in how the value gets transferred to the SCADA system. When you see 842018361, that's likely the integer representation of the ASCII characters being misinterpreted. To properly convert the value for iFix, you might want to try converting the DINT back to a string in the PLC before sending it to your SCADA system. This way, iFix should receive it in the correct ASCII format. You can also check if the IGS driver has any settings for handling ASCII values directly. If that doesn't help, it might be worthwhile to do the conversion manually in the Compact Logix, ensuring that the SCADA system interprets it the way you expect. Good luck!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: The discrepancy in values could be due to a conversion issue between ASCII characters and decimal values during data transfer.
Answer: Answer: To resolve this issue, you may need to implement a proper conversion method, possibly involving converting ASCII characters to decimal values before transferring the data to the SCADA system.
Answer: Answer: The suggested value of 50484657 as representing 20.9 may indicate a potential clue for understanding the conversion process needed to accurately display the gas monitor data in the SCADA system. Further investigation and testing may be required to confirm this conversion method.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.