I may have made assumptions that were too generous. Can you provide a thorough explanation of the specific ADD instructions and their corresponding values in both methods? Are there any circumstances in which the ADD no longer triggers at that specific level?
- 25-01-2025
- bernie_carlton
Yes, I have a Tag L55_4004_D17 (DINT) that is combined with a constant value of 3.12 (gearbox ratio) from another Tag L55_4004_AUXR13. The result is then shown to the operators for them to replace the roll sleeve after a set number of rotations. This scenario represents the maximum lifespan of the sleeve, as we rarely reach such high rotation numbers. The calculation involves adding the values of L55_4004_D17 and the constant 3.12 from L55_4004_AUXR13. When the operator resets, the L55_4004_D17 tag is reset to zero and increments by multiples of 3.12. I initially used a real number for the calculation, but the outcome was the same. I wondered if there was a constraint on adding real numbers and DINTs together. Thank you for your assistance.
The issue persists when dealing with different scales of numbers in industrial automation systems. While 1.0 may become insignificant to millions, 3.12 could become negligible when compared to a higher magnitude. Finding an alternative method to calculate rotations is necessary.
In ControlLogix, data types are automatically converted in the ADD instruction. This means that performing an addition operation between a REAL and a DINT can be done as REAL. However, the underlying problem lies in the IEEE 754 notation and the manner in which microprocessors handle floating-point values.
Is it possible to change the data type of tag L55_4004_D17 to accommodate decimal values such as 3.12 and 6.24? Instead of incrementing by decimal values, can we simply count Motor Rotations by 1's and then use a MUL instruction to calculate Spindle Rotations (Motor Rotations x 3.12) for display to operators?
While you are correct, the L55_4004_D17 feature rounds the number to an integer. The Voith Handbook provides values for the rotation of the Roll, not the motor. Despite Operations' preference for values in Sleeve rotations, they could easily multiply it by 3.12. My main focus was on understanding why it wasn't working, rather than simply correcting the Operator display. This led me to try adding two reals instead of a real and a DINT, but the results remained the same. I couldn't find any information in Rockwell Literature regarding limitations, and a search online yielded no satisfactory explanation. This prompted me to post it on a web forum. Thank you for taking the time to share your insights and experiences.
Perform an addition operation on 312 with DINTs, followed by dividing the result by 100 for the operators.
The processor is unable to directly add a floating-point number to an integer. It can only perform addition between two floating-point numbers or two integers. Therefore, when adding a REAL to a DINT in a processor, the DINT is first converted to a Real within the processor, the real addition is then performed, and the result is finally converted back to a DINT and stored in the DINT tag. This results in a resolution limit of 224-1 (16,777,215) for counting by ones, a common limitation across computing systems, including PLCs. Even 64-bit machines face resolution breakdown issues with real numbers. For further information on this limitation, consult Rockwell Knowledge Base technote documents 7765, 59372, 29562, 18209, and 29562.
Important resource: The Goldberg Variations by Oracle provides essential information on numerical computing, a valuable tool for programmers and developers. This comprehensive guide covers key concepts and techniques to enhance precision in computation. Access the document at http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html.
Ken Roach replied that he may have misunderstood your question. The Count Up (CTU) instruction in PLC programming will count up to the preset value set. Just to clarify, the CTU (or CTD) instruction functions as a counter and will keep counting even after reaching the preset value. The preset value simply triggers the "done" (.DN) bit. It is common to use A-B counters with a preset value of zero, essentially using them solely as counters without indicating completion.
When performing calculations in a PLC program, it is crucial to consider the data types of the operands involved. In this specific scenario, Source A is a DINT while Source B is a REAL. As at least one operand is a REAL, the processor will utilize the floating-point calculator for the computation. This means that the result will be rounded when stored back into a DINT tag. For example, adding 3.12 to a value stored in a DINT tag will result in a rounded value being stored, leading to data loss over time. It is essential to carefully plan and configure your tags and program logic to ensure accurate results. Remember, the way results are stored can impact the precision of your data.
While this thread may be old, a colleague recently posed a similar question to me. While many responses touched on the topic, none used apples for explanation - a key element. Let's delve into the significance of the magic number 67,108,864 in relation to IEEE Standard 754 Floating Point Numbers. As previously noted, this value marks the point where REALS increase linearly by one before transitioning to a non-linear increase. The subsequent value, 67,108,872, is 8 units higher. Consequently, if you add 3.1200 to 67,108,864, the result rounds off to the same value in the IEEE 754 standard. This phenomenon arises when dealing with small increments, eventually hitting a 'wall,' even if the increment surpasses 3.12 due to larger step sizes at higher values. Solutions to this issue include counting revs in a DINT for increased storage capacity, using a scientific calculator alongside the HMI for independent calculations, or adjusting targets by a factor of 3.12. While changing operator mindsets may prove challenging, it is preferable to navigating the complexities of floating values on a 32-bit CPU.
In a recent post by omar.fiscal, the value of IEEE-754 is discussed, with a sequence showing values ranging from 67,108,860 to 67,108,872. A minor typo was also mentioned and has been corrected. Click to read more.
Building upon the insights shared by @omar.fiscal, for those seeking a deeper understanding... Upon reviewing this discussion, the proximity of the "cap" to 64 million caught my attention, indicating it was approximately 4 times 16,777,216, a significant power of 2 value. To further explore this, I input the cap value into a calculator in Programming Mode, confirming its power of 2 representation.
The significance of 16,777,216 (224) lies in being the largest whole number in 32-bit REAL (IEEE-754 Single-Precision Floating-Point) that results from adding 1 to another whole number, due to the bit allocation in 32-bit reals (24 bits for mantissa, 8 for exponent, and 1 for sign). A more intriguing figure is 67,108,860, very close to the cap that sparked this discussion years ago.
Noteworthy are the binary digits (bits) in this context, such as the last two bits being 0 and the following 24 bits being all 1s, as highlighted. This situation can be likened to the use of scientific notation in a decimal display.
In a 32-bit REAL setting, values like 67,108,856 and 67,108,860 are represented in binary form with corresponding scientific notation values. The conversion process involves truncating least-significant bits, as evident when comparing the original and converted binary expressions. Notably, some bits are lost above and below the cap value, affecting the precision of the conversion process.
An insightful illustration of this phenomenon can be observed through a Python code scenario and output demonstration. This showcases the impact of converting integer values to 32-bit float (REAL) representation and back to integer form, highlighting the truncation that occurs during the process.
Overall, this analysis sheds light on the intricacies of binary conversion in the context of 32-bit REAL representation, emphasizing the precision limitations and truncation effects involved.