This is not just about scaling, but also about the bits involved. Following the arithmetic division, it is important to transfer the value (e.g. 71) - not just the bits- from memory location D1128/1129 to another memory location (e.g. Dnnnn) that will be utilized by PLSR. Learn more about this process by visiting our website.
To achieve the desired positioning accuracy without a closed feedback loop from an encoder, you can utilize the PLSY function to generate a specific number of pulses at a set pulse width. For instance, if 100ms pulse width requires 10000 pulses to complete a 360-degree rotation, and you only need 180 degrees, the calculation would be 10000/360 * 180, resulting in 4,860 pulses. It's important to note that since the function operates using long integers, floating-point mathematics cannot be used and the outcome will vary based on the pulse width setting.
To input data into the Human Machine Interface (HMI) in millimeters (MM) ranging from 1 MM to a maximum of 850 MM and initiate the rotation of a roller to cover that distance, a stepper motor is employed. Another avenue is then opened to carry out the task.
By utilizing the Pulse Accumulator (PLSR) along with a specific register within the D8000 range, you can track the number of pulses and compare it to the desired value. The PLSR function operates continuously, with parameter S1 representing pulse width and parameter 2 indicating frequency. This special register is crucial for stopping the drive once the designated number of pulses is reached for a given position. Furthermore, special registers like M8029 are activated once the specified pulse count is achieved. It is possible to monitor the pulse count sent to Y0 using D8140 and D8141, which can be used in comparisons to reset the contact driving the PLS function.
In a forum post, user zerocool666 shared a formula for calculating degrees of roller travel based on roller circumference measured in millimeters. The formula involves dividing the measurement in millimeters by the roller circumference and then multiplying by 360 to determine the degrees of roller travel. The next step is to divide the degrees of roller travel by 1.8 to find the number of steps for the driver. For example, using a roller circumference of 281mm, the calculation would result in 128.114° of roller travel and 71.174 steps. However, it's important to note the difference between floating-point values and integer values when working with device memory locations. The challenge arises when trying to pass a fractional (e.g. 71.174) value to certain instructions like PLSR or DPLSR, which interpret bits as integers. The issue at hand is ensuring the interpretation of bits aligns with the intended value type.
After realizing the limitations of the current function, I am exploring alternative methods to achieve my desired outcome. It is important to find a workaround that aligns with the functionality available.
When performing calculations involving floating point numbers, it is necessary to convert the result to an integer such as a single or double using the FLT_To_DInt (or Int) function. If you require a higher precision, you can utilize the DPLSR function to obtain a double. Another approach is to assume that the result needs to be in 0.1mm increments, in which case you can multiply your calculations by 10 for increased resolution.
To keep track of the number of pulses in the D8000 range, the PLSR function can be utilized. The special register in this range indicates the pulse count, with parameter S1 representing the pulse width and parameter 2 denoting the frequency. This information can be used for comparison, ensuring the drive stops once the desired pulse count for a specific position is reached. Furthermore, the special registers M8029, D8140, and D8141 can be used to monitor and analyze pulse count information for Y0. In the case of using PLSR for two separate rollers that must move different distances, consideration must be given to programming the function accordingly.
Looking for instructions on how to reboot a D8000 device?
An alternative approach is to perform all scaling operations in 32-bit integer format using DDIV and DMUL instead of DEDIV and DEMUL. This code snippet shows how to achieve this:
DMUL D1001 200 D1120 (200 steps to equal 360/1.8)
DDIV D1120 281 D1128 (per 281mm)
DPULSR D1128
Please note that adding the following code before the DDIV operation effectively rounds the result to the nearest step instead of truncating to the step at or below the result:
DADD D1120 140 D1120
The D8000 range contains registers, specifically D8140. To disable the PLSR (Y) function, simply input 0 into D8140 or any other register. When dealing with real numbers in float format, convert them to integers or double integers by multiplying them by the decimal places. This adjustment is necessary as PLS functions do not support floats.
I recently posted a message that doesn't seem to be showing up. I wonder if it got linked to another post. When the contact driving the PLS instruction is false, move 0 into the D8140 & D8141 registers (not D8000 as previously mentioned, most special registers are in the 8000 range). Here's a straightforward method to convert a float to an int or dint. Since the function doesn't support floats, multiply by 10 to shift the decimal place and then convert to an int.
When the PLS function is enabled, it likely resets itself. However, you can also reset it by inputting a value of 0.
When working with Mitsubishi PLCs, it's important to note that automatic data type conversions are not supported. If you have a floating point value stored in two D registers, you will need to utilize the INT instruction to convert the value into a 16-bit integer format before using it in operations that specifically require a 16-bit integer input.
It seems that the OP is utilizing only 32-bit DPLSR instruction, necessitating a double-check. Based on the formula you provided, approximately 71.xx pulses are required. However, the actual value should be rounded to either 71 or 72. It's important to consider that the width of the pulse will determine the distance moved per pulse, so refining this aspect can be achieved by adjusting the pulse time and increasing the number of pulses. Additionally, it's worth noting that Parameters S1 and S3 for ramp and pulse time have not been set yet.
¿Cuál es la instrucción adecuada para actualizar de la versión 71.xx a la versión 71? Muchas gracias.
To improve the resolution of your calculations involving floating point numbers, consider using the DINT function to convert a float to a double integer. This is especially useful if you require a higher level of precision, as multiplying the float number by 10.0 before converting can result in a more accurate representation. For instance, converting 71.2 X 10.0 to DINT would give you 712. This method can be particularly beneficial when dealing with measurements like degrees, where increasing the number of pulses per revolution can enhance resolution but also lead to shorter pulse widths and more pulses. The process of converting a float to a double integer can be achieved by following these steps.
zerocool666 asked how to upgrade from version 71.xx to 71. Can someone provide instructions on how to do this? View post #16 for more information.
The calculation @DR provided will not yield the desired result as D1001 contains integers resulting in a output of 0. In this case, the user will need to use floating-point numbers and then convert them to double integers for accurate calculations.
parky mentioned that the solution provided will not work due to the integer math calculations resulting in a value of 0. The best approach would be to use floats and then convert to Double integer. By rearranging the order of operations and using 32-bit integers, along with adding 140 after the multiply and before the divide, rounding can be implemented effectively. This adjustment ensures the desired outcome is achieved.
Thank you for your assistance and guidance. The issue has been resolved by simply adding 0.5 to the steps and then using the INT function to round the result.
The motion functions within the system can only accept integer or Dintegers as inputs since half pulses are not supported. Due to the floating point convention, data viewed as an integer may not be the same, requiring conversion. Many motion functions offer both 16-bit and 32-bit modes, such as PLSY and DPLSY. The "D" functions operate in 32-bit mode and should ideally be used with double integers. If your pulse amount is less than 32,767, regular integers can be used instead of Dintegers. However, when using the "D" functions, ensure that the second 16-bit word is not used elsewhere to prevent incorrect pulse outputs. It is important to convert floats to 32-bit integers when using 32-bit functions and avoid utilizing the second register in other parts of the program. Numerous instances have been observed where programmers have made this oversight.
Thank you for your input! I consistently utilize D100, D102, and D104 in sets to prevent any potential errors that may arise.
In order to prevent errors, I always make sure to use D100, D102, and D104 in pairs in my programming. It is essential to designate specific names for the registers and bits utilized in your code to avoid confusion. Additionally, setting aside a register area for interim calculations that can be reused throughout the program is recommended. I found it crucial to optimize register and bit usage, especially with limited capacity in the first FX and A series. Mitsubishi provides comprehensive programming manuals that offer valuable guidance for utilizing the instructions effectively. It is important to refer to these manuals for seamless programming.
It is important to highlight that instructions like DDIV produce a 64-bit output, spanning across 4 consecutive registers.
The now discontinued FX3 PLC allows for file memory creation, with the standard FX3U offering 16k of memory. Additional memory includes "R" memory with 64,000 steps of built-in program memory. The PLC can control 16 to 384 points with CC-Link or AS-i remote I/O. Other memory capacities include 7,680 points for Auxiliary Relays, 512 points for Timers, 235 points for Counters, 8,000 points for Data Registers, and 32,768 points for Extension Registers and Extension File Registers (with optional memory cassette). The A series PLC also offers extension registers options in the PLC Parameters.
Avoiding using excess memory space out of fear of overwriting memory locations is not recommended and indicates a lack of understanding. It is advisable to hone programming skills by practicing in assembly language, as was commonly done in the 1980s. During this time, limited memory space was a challenge for both data and program storage, but I managed to tackle complex tasks. This challenge was also present with the first FX series computers.
Back in its day, the AiS had 32k of memory while the A2 boasted 64k - a significant amount at the time. Memory cartridges could also be added to enhance storage capabilities. However, given that these models have been discontinued for approximately 20 years, their relevance has diminished. Despite this, many users overlook the "R" registers or file memory, which can be stored on expansion cards or in the main RAM. Additionally, without using PLC-PLC link modules, there are B bits and W words to consider. While earlier FX models had limited memory, current hardware like the FX5 has addressed this issue. The FX3, while still available, is not as popular as its successor. For latched memory, the FX series offers 13K of D memory. The R memory, though not explicitly latched, can occupy a portion of the 32/64k internal memory if stored in the built-in RAM. Even the PLC-5, a more advanced model, could only accommodate up to 100k of memory storage.
In 1988, I began programming my first Mitsubishi PLC, the A1. This model was larger than the A1S and A2S models I would later program. I used it to control a large porcelain firing kiln with multiple regulation loops. Since PID instruction was not available at the time, I developed my own regulation algorithms using integer arithmetic. Despite the lack of floating point support, I successfully integrated everything into the PLC program, taking a risk that paid off. While others opted for Eurotherm or Barber Colman controllers, I maximized the A1's capabilities. Additionally, I created a SCADA system from scratch for an 8088 computer with floppy disks. It's worth noting that the original FX model, specifically the one without a numerical identifier, had a limit of only 1000 Ds.
In the 1980s, I worked on an AFE graphics system for a steel tube manufacturing plant that utilized a Scada system. The company I worked for had their own PLC design. The system monitored the production process of creating tubes from flat steel coils, including shaping, welding, and cutting. I was responsible for developing calculations for the cutting data, such as tube dimensions, blade diameter, number of teeth, and pitch, to optimize blade lifespan. The calculations were complex and required extensive iterations to reach the desired values. Due to limitations with floating-point math support in MS C, we had to work with integer math until we obtained a floating-point add-on from a company called Grey Matter. Despite the challenges, I enjoyed the process of solving these mathematical equations. Unfortunately, I no longer have access to the formula, as my current math skills may not be sufficient to recreate it accurately.
As an enthusiast of integer calculations, it's crucial to exercise caution to prevent overflow errors. With advancements in PLC speed, I made the switch to floating point for my regulation algorithms after many years. This change not only allowed for faster calculations but also enabled me to utilize functions like square root with ease.
Back in the day, we had to separate numbers into integer and decimal parts for testing. The guy who developed the formula for tube sizes and thickness would input variables into his programmable calculator and run the program. Our system was much quicker, taking only 3 seconds compared to his 11.5 seconds (considering calls to utility code and graphics applications). The PLCs they used were cutting-edge, with one designer showing me the innovative functions, including FBD programming way ahead of its time. The plant I worked in was massive, with steel coils fed into machines for welding and forming tubes. The process was streamlined with automatic welding and cutting, creating a seamless production line. The setup was so vast that I needed a bike to travel from one end to the other.