New ✨ Introducing Oxmaint Asset Hub for Machine Builders and OEMs. Explore Now

Hello there! I need some guidance on how to convert an array of SINT[5] values into a Decimal format. The combined value of the array consists of 40 bits, which is too large for a DINT to accommodate. My objective is to obtain the Decimal value as a STRING within RSLogix 5000 v24. For instance, let's take an example with a Hex Array where SINT[0]=01, SINT[1]=2A, SINT[2]=64, SINT[3]=E0, and SINT[4]=CE. In Excel, you can use the function HEX2DEC(012A64E0CE) to calculate the value, which results in 5006221518. This process helps in efficiently converting hexadecimal values into their Decimal equivalents.

Employ bit shifting to transfer 4 pairs into a DINT for rapid transformation. Next, combine a real number with CPT to incorporate the leading pair multiplied by 16 to the power of 8 and 9.

It appears that the PLC may not support the necessary number of mantissa bits for REALs, as 40 bits are needed but only 24 are available in a REAL data type. Are LREALs supported by the target PLC? Additionally, clarification is needed on whether the 40-bit value is treated as a signed or unsigned integer. Furthermore, the byte order of the target PLC must be determined. The choice of programming language is also important to consider. While working with LREALs (and possibly UDINTs), having answers to these questions is essential for successful implementation. It should be noted that the data type in question is a SINT array, not a HEX array; HEX arrays do not exist.

In a recent discussion, drbitboy and @robertmeemeant discussed the limitations of using REAL data types in programmable logic controllers (PLCs). It appears that PLCs may not have access to the LREAL data type, which is necessary for handling 40-bit values. Additionally, they raised questions about the byte order, programming language compatibility, and the need to use alternative data types like UDINTs for such calculations. It was clarified that there is no specific HEX array, but rather a SINT array representing hexadecimal values. To address the challenge of handling 40-bit values, a strategy was proposed involving splitting the calculation into manageable parts. By breaking down the process and manipulating DINTs, the goal is to accurately convert a 40-bit HEX value into a 10-digit decimal number. The proposed method involves transferring bits from the SINT array to the DINT, analyzing specific bits to extract different portions of the decimal value, and combining the results to form the final 10-digit number. While the exact instructions for this logic are still being developed, the plan includes utilizing mathematical operations to extract and concatenate the necessary digits. In conclusion, the team is optimistic about the feasibility of this approach and believes that with careful planning and execution, the conversion process can be successfully achieved.

To improve the efficiency of your code, consider treating your 5-byte value as a 64-bit one. Search for an algorithm that performs 64-bit division within 32-bit registers and integrate it into an AOI design. These algorithms are widely available, as even Knuth dedicated a section to them due to their prevalence. By repeatedly dividing by 10 and referencing an ASCII table for the results, you can simplify your task. To optimize your AOI for handling 64-bit values divided by an 8-bit divisor, focus on the most common algorithm which involves a 64-bit dividend and a 32-bit divisor.

A five-byte integer consists of forty bits, allowing for unsigned values ranging from 0 to just over one trillion (up to 13 decimal digits). To achieve this, three AOIs can be utilized: 1) An adder AOI that takes two single-decimal-digit SINT inputs, processes them with a decimal carry in and out, and outputs a single SINT value. 2) A 13-decimal-digit adder AOI that utilizes the single-digit adder and processes two 13-digit SINT array inputs to produce a 13-digit SINT array output. 3) A conversion AOI that transforms a 5-element SINT array binary value into a STRING with its decimal representation. This AOI internally operates using two 13-element SINT arrays: Result (initialized to all 0s) and Increment (initialized with a value of 1 in the least-significant digit and 0s elsewhere). For each of the forty input bits, Increment is added to Result if the bit value is zero. Regardless of the bit value, Increment is added to itself. Subsequently, 48 is added to each element of Result, these values are placed into the .DATA elements of the output STRING, and the .LEN attribute of the output STRING is set to 13. Removing any leading zeros is left for the user to handle. While not the most efficient solution, this approach is relatively straightforward, making it easy to code and debug.

The following code section is a Python example, but it can be easily adapted to ST or LADder programming languages. The first four functions serve as the equivalent of AOIs, while the remaining functions are for formatting Python output. The initial segment demonstrates usage and results. Code:python b2d.py 01,2A,64,E0,CE ff,ff,ff,ff,ff ('0005006221518', (5006221518,), [1, 42, 100, 224, 206]) ('1099511627775', (1099511627775,), [255, 255, 255, 255, 255]) To convert sint5 to decimals, utilize the provided Python script, with functions to add digits and lists, as well as conversion procedures. Ensure proper input validation and handling for accurate results. If you encounter any issues, consult the additional struct and byte conversion functions included in the code for seamless sint5 handling. Test the script with specified arguments or modify it for custom input.

Incorporating ladder mnemonics for a 3-AOI solution is a smart way to enhance efficiency, although it may lack excitement. A solution with a few easily-understood rungs can be effective. Some individuals may opt to simplify the loops, allowing each loop's actions to be coded on a single rung with 1-3 branches. It is recommended to add comments for clarity. This code snippet demonstrates a function for adding digits and lists, as well as converting SINT5 values to decimals in a structured manner. The implementation includes detailed instructions and logic for seamless execution. The provided code can be optimized for improved performance and better readability.

Here is the current status of the Micro Starter Lite program: although it is functional, the speed may be a concern. When tested on an emulator, there is a noticeable delay of several seconds to acquire results. Fortunately, there seems to be no watchdog timeout issue with the emulator. It is anticipated that the program would run more efficiently on actual PLC hardware. However, it is currently processing between 1040 and 2080 additions per calculation, excluding the complexities of index manipulation and 2-level indirect data file addressing. Simplifying the loops or utilizing the scan cycle to optimize the program's performance might be worth considering, even if it means a slightly longer computation period for each new 40-bit integer input.

After reviewing all the responses, it seems that the total number of bits is 40, which is too long for a DINT data type. Why not consider using a LINT data type instead, which offers 64 bits of storage capacity? This should adequately cover your needs. It's important to note that each 8-bit (HEX) word corresponds to an ASCII character in the array, resulting in a string of 5 characters. While I attempted to convert them into a string, I encountered some non-printable values that appear to be non-HEX in nature but convert smoothly to Decimal (e.g. 01421001244206). Unfortunately, without more information, it's challenging to provide further assistance. In my experience, I've worked with equipment that transfers numbers in ASCII format, requiring a conversion to Decimal for usability. I hope this insight proves helpful for your situation.

GaryS expressed his thoughts on the responses received regarding the total number of bits in a data type. While the suggestion was made to use a LINT data type with 64 bits instead of a DINT due to the 40-bit requirement, there was also mention of ASCII values in hexadecimal format. It was noted that each HEX word represents a single character in the array, resulting in a string of 5 characters. Some values were found to be non-printable, leading to confusion about their HEX or Decimal conversion. More information is needed to provide further assistance, especially when dealing with equipment that transfers ASCII numbers requiring conversion to Decimal. The difference between FF FF (255 255) and OPs conversion (65535) raises questions about the intended use of the array elements as either individual numeric characters or a single number.

I was recently examining this information and it would be beneficial to understand its source, such as a power meter that could generate significantly high values, explaining the use of a 40-bit (64) integer.

In response to a discussion about the number of bits in a data type, GaryS suggested using a LINT data type which has 64 bits, instead of a DINT which may not have enough bits for the total number required. For those using a model of Logix that does not support LINTs or LREALs, it is still possible to manipulate the values by copying SINT array values into a LINT or constructing an LREAL from the SINT array values. However, it is important to note that there may not be equivalent functions like DTOS or RTOS for 64-bit data types in all programming libraries. PlantPAX Process Library may offer AOIs that can perform arithmetic operations on 64-bit values using two DINTs. Interestingly, the Timex/Sinclair 2068 used a floating-point data type with five bytes to achieve better precision than the four-byte REALs commonly used in PLCs during that time.

An efficient method for division by a constant involves utilizing a specific magic number for multiplication. These optimizations can also be used to calculate remainders, which are essential for converting base10 to ASCII. By combining these techniques with division using half-word registers, it is best to leverage existing code. In my experience, analyzing how MSVC generates assembly code led to the discovery of the magic number, which was truly fascinating. Here is the code snippet for dividing by 10 using the magic number approach: ```cpp int div10(int value) { mov eax, 1717986919 imul DWORD PTR _arg$[esp-4] sar edx, 2 mov eax, edx shr eax, 31 add eax, edx ret 0 } ``` However, if your goal is to divide by a half-word (64-bit dividend in 32-bit registers), the task becomes more challenging. In such cases, MSVC typically resorts to a library function: ```cpp int div10(long long value) { push 0 push 10 push DWORD PTR _arg$[esp+8] push DWORD PTR _arg$[esp+8] call __alldiv ret 0 } ``` It's important to note that attempting to create your own division algorithm for this scenario is quite complex, as experts in the field are actively researching and publishing on the topic. A suggested starting point could be Rockwell's L_DIV AOI, with the flexibility to adjust the input and output parameters to suit your specific needs.

@Cheesefaceexcellent! @OldChemEng successfully installed the code on the MicroLogix 1100, and it appears to be functioning well. The scan time (S:35; max S:22) is approximately 71ms (709 ticks of the 10kHz clock), significantly faster than the emulator on a Windows 10 VM within a Linux Mint laptop. With the default watchdog set at 100ms (10 x 10ms), there is minimal room for error. The code shared differs from the original concept, but both seem effective. The primary variance lies in the loop termination conditions, adjusted due to perceived issues with loop efficiency in the emulator. Notably, in an RSLogix/Studio 5000 AIO, the direct lookup feature eliminates the need for double-indirect lookup (N:[this]:[that]), potentially enhancing speed. Alternatively, optimizing loop structures or distributing work across multiple scan cycles can further improve performance. Although achieving a 70ms conversion time for a 40-bit integer into decimal digits for an HMI display is commendable, optimizing the process can be beneficial. Consider sending the 40-bit data directly to the HMI and performing the binary-to-decimal conversion using tools like VBA or Python/Jython for more efficient processing.

The initial loop setup is shown above. It currently operates in approximately 61 milliseconds on the 1100, making it around 10 milliseconds quicker. To enhance performance, I will be making a simple tweak: transforming the lower 31 bits of the 40-bit integer into decimal digits using DTOS (also known as AIC in the 1100), and handling the remaining 9 bits in the same manner as previously done.

By unrolling the inner loop and removing all indirect addressing in the add-two-decimal-digits functions, the scan time has been decreased to 22ms, resulting in a significant 60% reduction.

Drbitboy made significant improvements to the add-two-decimal-digits routines by unrolling the inner loop and removing all indirect addressing, resulting in a 60% reduction in scan time to just 22ms. This optimization effort is akin to a dog with a bone, relentlessly striving for microsecond precision.

robertmee expressed his determination by stating "Dog with a bone..." and emphasized his unwavering stance by adding "Won't change my mind, can't change the subject." It's interesting to note that the original poster (OP) has been absent for some time now, indicating that they may have resolved the issue themselves. It crossed my mind that someone may have deliberately provoked me for amusement, highlighting my strong sense of self-awareness and confidence. While not yet precise down to microseconds, the current accuracy of 11ms may be sufficient for certain applications.

By first incorporating the high 31 bits into the initial string, we can efficiently double the string's digits for the remaining 9 bits. In addition, adding 1 to the doubled last digit for each remaining bit value of 1 eliminates the need for separately doubling the increment. Utilizing pairs of digits in the two bytes of a word, as seen in the MicroLogix 1100, enables the doubling of both digits simultaneously with some bit-twiddling for implementing decimal carries. These optimizations, coupled with loop unwinding, can reduce the scan cycle time to under 8ms. The Studio/Logix 5000 version promises a simpler process due to enhanced string handling capabilities.

**Answer:** To convert an array of SINT values to a Decimal format in RSLogix 5000, you can combine the individual SINT values and then convert the resulting Hex value to Decimal. This can be achieved by following a process similar to the HEX2DEC function in Excel.

**Answer:** When the combined value of the SINT array exceeds the capacity of a DINT in RSLogix 5000, converting it to a Decimal STRING allows for efficient handling and manipulation of the large value within the program.

**Answer:** Suppose you have a Hex Array with values SINT[0]=01, SINT[1]=2A, SINT[2]=64, SINT[3]=E0, and SINT[4]=CE. By combining these values and converting the resulting Hex value to Decimal, you can obtain the equivalent Decimal value, such as 5006221518 using a similar process to the HEX2DEC function in Excel.

sign in. Otherwise, register and sign in.