In my structured text, I am working with data structures sourced from a PC. The data is formatted in the "new" LREAL 64-bit floating point style, a novelty introduced by Rockwell in V32 from 2019 (though it was first seen in the computing world with the Intel 8087 math coprocessor in 1985). Although most operations are functioning as expected, I have encountered a limitation when attempting more complex CPT expressions. While simple assignments and basic arithmetic operations work smoothly, combining subtraction and multiplication in a single line triggers an error due to extended datatypes not being supported in expressions. Is there a workaround for this restriction? I am aware of using prefixes like 16# and 0b for hex and binary literals, but is there a similar method, like 'f' or 'l' in the C language for 32- or 64-bit float or long types, to specify the treatment of a number as LREAL? Upon further investigation, it appears that it is the combination of subtraction and multiplication in one line that causes the issue. While addition and subtraction or multiplication and division can be combined, Rockwell seems unable to handle adding and multiplying within a single expression. A solution is to split the operation into two lines for complex expressions, though this can become cumbersome for lengthier calculations.
The calculation is now condensed into a single line: Panos[i].Width is determined by multiplying the difference between Centroids[i].Y and Previous_Left by the constant 2.0 (Lreal2). This optimization simplifies the code for better readability and efficiency.
After writing the post draft, I attempted to use the following image: https://i.imgur.com/5Ad59xo.png However, the issue is not with literals but with 'extended' datatypes which cannot be used in expressions with more than two terms.
Rockwell offers a range of AOIs specifically designed for complex mathematical calculations. These AOIs can be accessed in their process library, available for download on their website. While Rockwell's solution may not be ideal, it is currently the most efficient option. Personally, I have created my own AOIs as I found Rockwell's offerings to be subpar; however, they should suffice for your current needs.
In fact, you're correct that extended datatypes aren't supported in complex CPT expressions in Rockwell's program. Your observations are proving to be quite insightful and you've already pointed out one of the common workarounds which involves dividing complex operations into simpler ones over multiple lines. As far as I'm aware, there aren't any prefixes analogous to 'f' or 'l' in C language that you could use here. The tedious reality is that more complex or longer calculations may require dividing them into even more lines. A more effective approach might be to break down your calculations into smaller units, potentially encapsulated within function blocks, for clarity and ease of debugging down the line.
Really interesting point you make about the limitations of LREAL operations. Unfortunately, I don't believe Rockwell has yet provided a direct way to specify a variable as LREAL similar to the 'f' or 'l' in C language. However, there is an indirect workaround that I've found useful in such cases. You might have to break down your expressions into simpler parts, storing the intermediate results in temporary LREAL variables. Sure, it might make your code a bit bulkier, but it keeps the operations clean and free from errors. Until Rockwell optimizes their handling of complex expressions, I guess we'll have to stick to this method.
It sounds like you're really diving deep into the nuances of Rockwell's handling of LREALs! Unfortunately, there isn't a direct way to specify an LREAL type inline like you can in C with 'f' or 'l'. Your observation about Rockwell’s limitation with mixed operations is spot on – it can definitely be frustrating. Splitting complex expressions into two lines is a common workaround, but to streamline things, consider creating separate functions or subroutines for your calculations. This way, you can encapsulate those operations without cluttering your main code and maintain readability. It might take a bit more upfront work, but it could save you from headaches later on!
It sounds like you've really delved into the intricacies of working with LREAL types! Unfortunately, the limitation you mentioned with combining subtraction and multiplication in one line is a common hiccup when dealing with these data types in structured text. Splitting the operation into two lines is indeed the go-to workaround, though I get that it's not the most elegant solution for complex expressions. While I haven’t come across a specific prefix for LREAL like in C, have you tried using temporary variables for intermediary calculations? It might help keep things a bit cleaner while also making the code easier to read and debug!
I can totally relate to your frustration with those limitations in handling LREAL types in structured text! It seems to be a common issue where specific combinations like you mentioned just don’t play well together. Splitting complex expressions into multiple lines is definitely a workaround, albeit a bit tedious. Have you tried using intermediate variables to store partial results? It might help streamline your calculations and make everything more readable without cramming too much into one line. Sometimes a clearer approach can save time and hassle, especially for more intricate calculations!
✅ 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: - When attempting to combine subtraction and multiplication in a single line of code, Rockwell Structured Text may trigger an error due to extended datatypes not being supported in expressions.
Answer: - One workaround for this limitation is to split the complex operation into two lines of code, handling subtraction and multiplication separately. While this may become cumbersome for lengthy calculations, it can help overcome the issue.
Answer: - Currently, Rockwell Structured Text does not provide specific prefixes like 'f' or 'l' in the C language for specifying 32- or 64-bit float or long types. The datatype handling in Rockwell Structured Text may require operations to be split into separate lines to work around limitations.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.