Hello everyone, I am currently working on a rehabilitation project and facing some challenges. Please refer to the screenshot below for more details. In the Local:5:I.Data[6] in BTD instruction, a data point is extracted from a DeviceNet 32-bit DINT. The instruction reads only half of the data point (16 bits), suggesting a possible switch in register order. However, I may be mistaken in my interpretation. I have observed a conversion of a value from 832246557 to 4983, followed by a multiplier to scale the value to ENG units, possibly kPa. My main concern is determining the 0-100% scaling and calculating it based on the provided information. I am unsure if this involves proportional scaling of an INT value using 2 147 483 647, potentially resulting in a 735 kPa transmitter exceeding 100 PSIG. If you have any insights or understanding of this process, please do share.
The Local:5:I.Data[6] display of 832246557 in decimal form may seem nonsensical at first glance. However, it actually represents two 16-bit analogue signals combined into a 32-bit integer. By utilizing BTD instructions, the lower and upper 16 bits are separated into new addresses for manipulation. To determine the scaling of these signals, having reference points or understanding the analog resolution is essential.
Dalporto inquired about determining the actual scaling from 0-100% and how to calculate it based on available information. The maximum range of the instrument with 16-bit raw count value for pressure is 0-65535, translating to 4250kPa. Since a 16-bit ADC for the transducer signal is uncommon, it is more likely that a 14-bit ADC is used, providing a range of 0-16383 or a 13-bit range of 0-8191, equaling approximately 1063kPa or 531kPa, respectively. The actual instrument range might be lower. If you have insights on this, please share. Regarding the decimal representation of 832246557, this is a 32-bit DINT from DeviceNet containing two 16-bit values for pressure and temperature raw counts. These values are combined by shifting the temperature raw counts' bits 16 bits to the left. The decimal equivalent of 832246557 is represented in hexadecimal as 0x319b131d, which breaks down to 12699 for temperature and 4893 for pressure. This process involves careful bookkeeping.
After gaining a better understanding, I will retrace my steps to ensure we are aligned. The setup includes an AI 1793-IE4/A module on a remote 4-20mA IOFlex rack receiving data from a DNB DeviceNet Scanner on a L71 rack. Upon review in RSNetWorx, it appears scaling options are limited. This means that any signal input across the four channels will produce the same value at the BTD destination. To determine the scaling of the instrument, knowing the maximum BTD value is crucial since it involves a simple multiplication process. Given that data from the 1793-IE4/A is a 2-byte register, it is essential to calculate the maximum range achievable at the Destination when the signal reaches 20mA. Can any insights be extracted from the .dnt config to assist in this process?
If the module is set up for 4-20mA with a current of 20mA, a reading of 30840 should be displayed. Please refer to page 691793-um001 in the user manual for more information.
Chelton mentioned that with the module set to 4-20mA at 20mA, you would typically observe a value of 30840. Refer to manual page 691793-um001 for more details. This information is exactly what I was searching for, especially for a 0-2000 kPa transmitter. It's interesting how this calculation results in a precise number. While it's uncommon for me to see pressure transmitters in kPa, it seems like a bit excessive to operate at 300 kPa. I will double-check with other values to ensure accuracy, but so far, everything looks promising. Thank you for providing this valuable information. I reviewed several general "FLEX" resources but neglected to refer back to the original source. My apologies for that oversight.
You're on the right track with your analysis! When interpreting the 32-bit DINT, you must consider the possibility of high and low word swapping. Typically, PLCs show issues like this when extracting data from a third-party device. Remember, the DeviceNet order might not match that of the PLC's native handling. The conversion you're seeing, turning a fairly massive number into 4983, might also indicate a factor you may not know yet. For scaling purposes, you might need to use those transformed units you mentioned, like kPa, and not the direct mapping from DINT. If your PLC is extracting only half of the point (16 bits), I'd double-check how you're reading and interpreting those 16 bits. The scaling, displayed as 2 147 483 647, would certainly be inconsistent if you're only reading 16 bits at a time, as that value is well within the 32 bit range. Lastly, remember that pressure transmitters usually have their own scaling factor, so try retrieving details from device documentation or the manufacturer if possible.
✅ 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 BTD instruction in RSLogix is used for extracting data from a 32-bit DINT in a specific format. It reads a specified number of bits from the DINT.
Answer: Answer: When the BTD instruction reads only half of the data point, it could indicate a possible switch in register order. Check the data format and ensure it aligns correctly with the instruction.
Answer: Answer: To calculate scaling for values extracted using the BTD instruction, you may need to observe conversions and multipliers applied to the data. Understanding the scaling parameters provided can help determine the 0-100% scaling for further calculations.
Answer: Answer: Proportional scaling with INT values using 2 147 483 647 may lead to issues such as exceeding the expected range. It's essential to carefully consider scaling factors to prevent inaccuracies in data interpretation.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.