Ready to Optimize Your Maintenance? Try It Free
Hello everyone, I am seeking assistance in writing a code for S-curve motion profiles consisting of 7 segments to regulate the speed of a motor through a PLC. I am struggling to find the equations needed for each segment. I require help to control the time, ensuring that I reach the setpoint within the same time frame whether I use linear ramping or S-curve ramping. While I am aware that my drive supports this function (Siemens G120), I need to implement S-ramping within the PLC for my specific application. Thank you for your help. Warm regards.
TurkSaleh is seeking assistance with programming S-curve motion profiles with 7 segments to regulate the speed of a motor through a PLC. While the Siemens G120 drive supports this feature, the specific equations for each segment are unavailable. This task may be challenging to execute within a PLC due to potential unexpected scenarios. For example, not all moves will contain 7 segments, and determining peak velocity or acceleration can be complex if the commanded values are not reached. It is crucial to consider factors such as short moves and scan times when implementing S-ramping in a PLC effectively. Only a few individuals have successfully addressed these challenges, highlighting the intricate nature of this task.
According to Peter Nachtwey, implementing complex calculations in a PLC may seem challenging at first. However, it is actually quite feasible if the calculation time aligns with the overall operational timing. It all comes down to meeting your specific requirements. For instance, I have witnessed turbine controls utilizing variable guide vanes with software-based floating point calculations and advanced mathematical methods like Heron's method for square roots and 3D map interpolation. Despite taking 20 seconds for calculations, it can still be achieved with the right knowledge and understanding of limitations, even on a budget-friendly controller.
Peter Nachtwey stated that performing certain calculations in a PLC may seem difficult, but it can actually be quite manageable. The key is to calculate points for time, position, velocity, and acceleration, ensuring that some points may overlap depending on the parameters. By simplifying the calculations with symmetric jerk and acceleration values, or considering asymmetric profiles, the task can be achieved effectively. Running the profile involves monitoring time and position, applying the relevant equations for instantaneous velocity, and comparing expected versus actual position. This process helps in fine-tuning the control loop by adjusting the proportional gain. It is essential to ensure that the PLC can update swiftly for the application's requirements, potentially offloading complex profiles to drive hardware for higher speeds. Profiles with lower update frequencies can comfortably be handled within the PLC, although certain terms like Jerk may be omitted if unnecessary.
Let's wait for the response from the original poster. It's important to note that a G120 is not suitable for servo drives, which means precise movements and high accuracy positioning may not be achievable.
JRW commented on the OP's question about the G120 not being a servo drive, indicating that fast moves and high accuracy positioning may not be achievable with it. However, the limiting factor in a PLC-based motion profile is typically not the drive itself, but rather potential communication limitations. JRW shared their experience with using open-loop drive control on an induction motor for PLC-based motion profiles, noting that application details are crucial. They highlighted an instance with a Parker VFD over EtherNet/IP where the drive lagged significantly despite the motion profile running smoothly in the PLC. Despite attempts to address the issue with Parker, adjustments to latency offsets and speed were the only viable solutions.
Hey there! S-curve motion profiles can indeed be quite tricky to implement. Generally, these profiles can be broken down into the acceleration, constant velocity, and deceleration phases, each designed to eliminate sudden changes in speed, thus reducing the jerk. Perhaps, you can calculate each segment individually, using kinematic equations. This would offer a smooth, continuous, and controlled motion across each segment. For tracking your time, you could set up a high-speed timer in your PLC, adjusting each motion ramp until you're synchronized. I would recommend contacting Siemens support too, they're pretty helpful with these issues. Persistence is key here, keep experimenting and you'll get there. Good luck!
Hey there, it seems like you've got quite a task on your hands. I have some experience with S-curve motion profiles. For each of the seven segments, a cubic or quintic equation will be utilized to achieve the desired curve profile. Regarding the timing issue, if your intention is to maintain the same time frame regardless of linear or S-curve ramping, then you'll have to adjust the acceleration and deceleration times accordingly. Keep in mind that for S-ramps, acceleration is not constant, hence you might need to put more attention into the exact timing. Regarding implementing S-ramping in a PLC, you would need to program your PLC to control the acceleration and deceleration of the motor to mimic the S-curve. Unfortunately, I don't have specific experience with Siemens G120, so I suggest referring to their instruction or user manual for precise details. Hope this leads you in the right direction!
Peter Nachtwey expressed challenges in programming motion control tasks on a PLC due to various complex scenarios that can arise. These scenarios include moves with fewer than 7 segments, where reaching commanded velocities or accelerations may be difficult. This leads to the need for determining peak velocities and accelerations, which can be a daunting task for many. Additionally, timing constraints such as scanning intervals can pose difficulties in ensuring all code is executed efficiently. Despite these challenges, the effectiveness of Delta motion controllers, particularly when used with RMC Tools software, cannot be ignored. The speed and capabilities of controllers like the RMC150 offer impressive motion control capabilities. This has led to a preference for Delta controllers in motion control applications. While some may argue that PLCs are not suitable for complex motion control tasks, it ultimately depends on the PLC model and communication protocols in use. For example, setting up dedicated tasks for motion control with a fast scanning time on a PLC can yield successful results, as demonstrated in a setup managing various tasks including motion control, machine control, IO, and data acquisition. Furthermore, utilizing protocols like EtherCAT can enhance communication efficiency in PLC-based motion control systems.
Executing long moves becomes simple when the target trajectory reaches the specified acceleration and velocity. However, challenges arise when these parameters are not met. A discussion took place over a year ago involving cheeco, a German engineer at ESA in Lieden NL, showcasing his software for creating optimal motion profiles using 3rd order polynomial segments. Despite encountering a bug initially, Cheeco promptly resolved the issue. Cheeco and I are among the few who have successfully tackled what I refer to as the "problem from hell". It involves transitioning from any Position-Velocity-Acceleration (PVA) to another PVA in the shortest possible time, a test I use to assess competitor controllers. This task becomes complex when the desired velocity and acceleration are not achieved. This challenge is so perplexing that a professor at Fordham University referenced it in one of his presentations, utilizing the Fermat program to solve it. However, the solution is impractical for real-time applications due to its lengthy processing time. Mathematica can also address the issue, but the solution is inefficient for the same reason. A search for Cheeco in the forum will yield two relevant threads. I have developed a program capable of testing various move combinations from any initial PVA to a final PVA. After conducting 200 trillion iterations, I identified and rectified numerous flaws in my software, ultimately achieving flaw-free moves. This experience has equipped me with the skills to identify issues in motion controllers effectively. Delta is set to introduce Ethercat capability within the year, primarily for controlling output devices like valves and drives. My concern with Ethercat lies in the fact that its packets are essentially CAN Open packets on Ethernet, limited to 8 bytes of data. This restricts the transmission to a 32-bit float and command bits specifying the float's purpose, typically a position. Although positioning can occur every 50 microseconds, there is a lack of feed-forward data, target velocity, and acceleration - only a target position. As a result, Ethercat proves useful for transmitting output values to valves and drives but falls short in delivering motion profiles to multiple controllers effectively.
TurkSaleh expressed frustration in finding the necessary equations for each segment and is seeking assistance. A quick Google search provided various answers related to 7 segment motion control. However, these answers may not address specific edge cases or constraints not yet disclosed by TurkSaleh. It is important to determine if TurkSaleh's PLC can handle the problem at hand.
Peter Nachtwey emphasized the importance of efficiently transitioning between any given position, velocity, and acceleration (PVA) states. This process is crucial for achieving optimal results within a specified timeframe. It is essential to determine whether the goal is to achieve optimal time or simply meet specific constraints when solving the general case.
Thank you for all your support. Providing more detailed information is essential. My system is equipped with a Siemens 1515 CPU and a G120 drive from Siemens. The task at hand is fairly straightforward and should be within reach. The ramp up and down time is set at 20 seconds. For this particular project, the setpoint will remain constant during the ramping process. The drive features an extended ramp function that I aim to implement within the PLC. This function allows for the configuration of initial and final rounding times, resulting in a smoother s-curve ramp instead of a linear one. While I have come across several SRamp functions, such as those found in the oscat library, they do not allow for the direct setting of ramping time. This can pose a challenge for operators when adjustments are needed. I stumbled upon a detailed discussion between Peter Nachtwey and Checco, which may be too advanced for my current needs, but I am eager to explore programming possibilities. Unfortunately, the provided links are not functioning properly.
TurkSaleh mentioned:@Peter Nachtwey I came across the conversation between you and Checco, which seems a bit too advanced for my current project. However, it would be beneficial if I could implement it. By the way, the links provided are not functional. When starting and stopping with zero velocity, you may not require all the components mentioned by Peter. This level of complexity may be excessive for such an application. In cases where parameters may vary, it is important to consider reaching the maximum velocity and acceleration. Once these values are established, it is possible to calculate the profile points accordingly. If limitations are encountered in either velocity or acceleration, certain segments may be excluded, resulting in identical points. It is recommended to have a basic understanding of calculus to effectively complete this task.
TurkSaleh mentioned that the application is straightforward and easily attainable. The ramp up/down time will be 20 seconds or more, with a constant setpoint throughout. The drive features the extended ramp function required for this task, which needs to be implemented within the PLC system. Do you need to execute a motion profile or simply create a speed reference using an s-ramp from the PLC? Please provide further details about the specific application at hand.
Is the performance of the application restricted by jerking or acceleration limitations? The reference to 7-segment profiles by the original poster suggests that it is likely the former.
Inquiry by drbitboy about whether the application is limited by jerking or acceleration. Based on the mention of 7-segment profiles by the OP, it seems to be jerk-limited. It would be beneficial to receive more precise information regarding the OP's intentions.
Have you checked out the Ramp Generator feature in the Siemens Converting Library on TurkSaleh's website? This tool can help you easily create ramps for your projects.
Similar to the G120's RFG, but with a PLC-based system.
User jhenson29 inquired about the necessity of running a motion profile versus generating a speed reference as an s-ramp from the PLC. More details on the specific application were requested. However, it was clarified that a smooth acceleration speed reference at the start and stop points should suffice in this scenario.
According to JRW, the system is akin to the G120's RFG, but it is PLC-based, which is exactly what I was looking for. Understanding the mathematical and physical principles behind this block is crucial for its operation.
If TurkSaleh is using a Siemens PLC, I highly recommend following JRW's advice and utilizing the library. We tested it for comparison and found that it functions effectively. It is always preferable to utilize a library that has been thoroughly debugged rather than attempting to recreate it from scratch. Drbitboy, it's time to utilize your Python and Sympy skills to solve the 17 equations for 17 unknowns. Assuming all 7 segments are being used, the 17 unknowns include t01, x1, v1, t12, x2, v2, t23, x3, t34, x4, t45, x5, v5, t56, x6, v6, t67. This calculation assumes that point 0 is the starting point and x7 is the ending point. The initial and final PVA are known, and the commanded P, V, A values are provided. It's not necessary to consider all the information Peter mentioned. In my scenario, the motion controller must have the capability to generate any motion profile as requested by the customer. Whether or not the equipment can actually follow it depends on the designers. The OP's mention of 7-segment profiles suggests the former. It should be noted that achieving the commanded acceleration and velocity may not always be possible for short moves, as in the case of only 3 segments being used and the motion being jerk-limited.
Peter Nachtwey noted that achieving commanded acceleration and velocity during short moves may be challenging. When there are only a few segments involved, motion is often constrained by jerk limitations. The question arises: is it the acceleration or jerk that exhibits a Heaviside Function-like profile, with discontinuities in the motion? According to the image from JRW in the Siemens library, it appears that acceleration is the parameter showing discontinuities.
In a discussion with drbitboy, the focus was on whether acceleration or jerk exhibits a Heaviside Function-like profile, specifically if it is discontinuous. The image from the Siemens library by JRW appears to show that acceleration is discontinuous. However, motion profiles seen on a S7-1500T display true 7 segment motion profiles that are not optimal and difficult to use. The accelerations are either constant or ramp up/down based on the jerk rate, with continuous segments and only changes in jerk occurring in steps. The question remains, where can one find solutions for the 17 unknowns?
Peter Nachtwey asked: Where can we find solutions for the 17 unknowns? I am searching for the equations. It seems like the delta link is not working, or perhaps I overlooked it. Can anyone provide insights on this matter?
Thomas_v2 mentioned that solving turbine control equations is not overly challenging. However, simply programming the equations without truly understanding them or the time it takes to execute them may not be very effective. It is important to derive the equations using sympy, as recommended. Siemens offers a library for this purpose, but what JRW shared is not the correct one. For more information on s-curves, check out this old discussion thread: http://www.plctalk.net/qanda/showthread.php?t=35902&page=2.
Peter Nachtwey recommended using sympy to derive the equations instead of what JRW presented, as Siemens offers a library for this purpose. However, it should be noted that the library is not compatible with g120, does not support DSC, and requires telegram 105.
Peter Nachtwey mentioned that Delta plans to incorporate Ethercat capability this year, mainly for controlling output devices like valves and drives. However, Peter expressed concern about Ethercat packets being similar to CAN Open packets on Ethernet, with limited data capacity. While Ethercat is suitable for sending output values to devices, it may not be ideal for complex motion profiles across multiple controllers. Peter reached out to Delta to inquire about the availability of EtherCAT in their controllers for an upcoming machine build scheduled for the end of the year. Despite limited information on a timeline from Delta, Peter is considering including the RMC-200 controller in their component list. In addition, new standards like EtherCAT-G and G10 were introduced last year for transmitting high volumes of data in motion and vision applications. Peter is not well-versed in these standards but plans to explore them further.
I found the perfect resource at the library LCon_RFGJ that provided exactly what I needed. Thank you to everyone involved in the discussion for helping me learn so much.
Peter believed that only a reputable RMC (Reconstruction Management Company) had the capability to handle the task effectively.
Peter believed that only an RMC was capable of achieving the desired outcome, contrary to JRW's statement. While Siemens does have a library that could suffice, the presence of discontinuities in the output acceleration (shown by the dark blue line) is concerning. The red line appears to be the integral of the blue line or velocity, while the green line seems to represent velocity without s-curves. It is evident that the RMC can perform better. The challenge remains in finding the equations for the 17 variables mentioned earlier. Without a clear understanding of these formulas, claiming that programming them in a PLC is simple is unfounded. Siemens' performance in handling even a basic scenario like the one described above is questionable. It is worth noting that Siemens previously utilized RMC100s for their plastics solution before introducing their own alternative in the late 1990s and early 2000s. Presently, both Siemens and Delta seem to focus less on plastics, as many OEMs prefer customized solutions over pre-made packages. While Delta and Siemens offer components, some level of assembly is typically required. Nevertheless, there is still a demand for RMC75s in plastic applications, especially for retrofit projects.
JRW stated that Peter believed only an RMC could accomplish a certain task. However, Peter clarified that he did mention Siemens has a library that could potentially work, but there are still concerns about discontinuities in the output acceleration. It appears that the red line may represent the integral of the blue line, while the green line seems to show velocity without s-curves. The RMC has the capability to perform better in this scenario. Peter is still waiting for someone to identify the equations for the 17 variables listed. Without knowledge of the formulas for these variables, it's difficult to claim that writing the code in a PLC is simple. It's evident that Siemens has not yet perfected the solution, even in a basic case as described above. Peter recalls being called arrogant by JRW. It should be noted that Siemens utilized RMC100s for their plastics solution in the late 1990s and early 2000s before introducing their own solution. Currently, it seems that both Siemens and Delta are less involved in plastics applications, as many OEMs prefer customized packages. Delta and Siemens mainly provide components, requiring some assembly. Despite this, a few RMC75s are still being sold for plastic applications in retrofits.
This is just one of the numerous methods available for tackling 7-segment displays. In scenarios where t56 is negative, it is advisable to flip the sign of all known PVA values and run the calculation again. While there may be some sign errors initially, the overall mathematical formula is accurate. In conclusion, this methodology is a reliable solution for addressing 7-segment-capable cases.
Thomas_v2 mentioned that achieving a tolerance of +/- 0.1" without the use of motion controllers is quite manageable. I have successfully accomplished this task in the past, where precise control was not necessary.
In a discussion by drbitboy, one possible method is outlined that addresses cases compatible with 7-segment displays. If t56 is a negative value, the sign of all known Position-Velocity-Acceleration (PVA) values should be reversed and the process repeated. Although there may be sign errors present, the foundational structure is accurate. The attached document provides further clarification. The equations provided for calculating position are correct, but it is essential to also determine the corresponding times. A positive value for t56 is typical, except in scenarios where the deceleration is minimal and the peak deceleration (negative acceleration) is not achieved. In such instances, t56 is zero, indicating the absence of that segment. Similarly, t12 or t34 could be zero, suggesting the absence of a constant velocity segment. It is crucial to identify the maximum velocity attained in these calculations.
In a statement by Peter Nachtwey, it is highlighted that the peak velocity magnitude (V) is a crucial parameter in the formula provided, especially for cases with non-negative values of t34, t12, and t56. This formula involves a variable time (t34) at a velocity with a magnitude of V, ensuring that max acceleration/deceleration (+/-A) is always achieved. While the post does not aim to solve all general cases, it addresses the ongoing requests for 17 equations. Deriving optimal solutions relies on these 17 equations, or a subset of them, along with meticulous record-keeping. It is essential to consider the times computed for a seven-segment profile, with t34 playing a key role. If t34 is negative, it indicates the need for adjustments in the profile's jerk values and peak velocity limits. There are only four key equations involved in this process, with the remaining tasks revolving around organizational matters.
In order to find optimal solutions for all scenarios, one must utilize a set of 17 equations, or a subset of them, along with detailed record-keeping. While solving this complex problem manually may be challenging, employing a Python package can simplify the process. If t34 is negative (not t56 - as mentioned in post #31), it indicates two possibilities. Firstly, the 7-segment profile should begin with a negative jerk, necessitating an inversion of the PVA inputs. Secondly, the peak velocity must be limited, resulting in a 5- or 3-segment profile with specific conditions for jerk values and time intervals. Deciding between a negative or positive jerk can be determined, but adjusting the PVAs may be a simpler coding solution. When moving in the positive direction, the initial jerk should always be positive. Notably, t12, t34, and t56 should never be negative. A negative solution for t34 denotes that segment 4 is non-existent, preventing the attainment of the target velocity. The only scenario where the initial jerk should be negative is if the actuator is slowing down, typically in response to a command during motion. Calculating or modifying motion profiles dynamically has not been addressed. Contrary to the notion of 17 equations, there are actually four core equations involved. It is crucial to understand that solving for the 17 unknowns requires 17 equations, which is applicable only when all 7 segments are present. The determination of segment existence by the target generator necessitates a distinct set of equations for each case. Highlighting the complexity of motion control programming, it extends beyond a mere PID loop linking an encoder or rod to an output. The target generator is the pivotal component that distinguishes an effective motion controller from an inefficient one.
Peter Nachtwey jokingly mentioned his trolling behavior in response to comments about the perceived simplicity of programming in a PLC. While acknowledging Nachtwey's expertise in the field of motion control, a user expressed a belief in the capabilities of PLCs but emphasized the complexity involved. In planning for future machine builds, the user intends to combine an RMC controller with a PLC for enhanced functionality. The user appreciates the user-friendly nature of RMC software, which allows technicians to easily create their own programs without the need for specific coding. They look forward to full EtherCAT support in the future and express a desire for additional features such as the ability to modify motion commands via .NET.
In a discussion on mathematical equations, Peter Nachtwey disputed the claim that there are only four equations, emphasizing that there are actually 17 equations that represent the same system. He also mentioned the importance of understanding the integrals and discrete functions involved in the calculations. Overall, the conversation highlights the complexity and interconnectivity of mathematical concepts in physics. Additionally, Peter extended an invitation to meet in person in Rochester to further discuss these topics.
A forum member, busarider, expressed belief in the capabilities of a Programmable Logic Controller (PLC), though acknowledging its imperfections. A previous discussion on PLC vs motion controllers highlighted the benefits of using motion controllers, with common questions about their capabilities. Have you heard of RMCLink, a .NET assembly that enables programming of the RMC using various languages like Excel, C, Visual Basic, and Python? Another forum member, drbitboy, suggested meeting in person in Rochester or virtually via Skype to share screens and discuss topics like control problems and education. For example, a forum member named Pandiani sought help as a college student and advanced to overseeing controls for power plants in Tuzla, Bosnia, with guidance and resources from the forum. The thread also explored the challenge of generating 17 equations related to a specific target generator, referencing Cheeco's 3rd order generator as the only one to pass the tests successfully. Understanding the significance of math and physics in solving such problems was emphasized, even though integrals and the discrete jerk function presented challenges in the process.
A forum member, busarider, expressed their belief in the capabilities of PLCs. The original poster (OP) may have found a solution, but it is not flawless or ideal. Over a year ago, I started a discussion comparing PLCs and motion controllers, highlighting the many reasons why one should consider using a motion controller. People often inquire, "Can your motion controller perform this task?" My response is usually, "Can you design a machine that can achieve this?" Additionally, have you heard of RMCLink? It is a .NET assembly that allows programming of the RMC using Excel, C, Visual Basic, Python, and more. Another member, drbitboy, suggested meeting in person in Rochester, but I proposed meeting via Skype and screen sharing. I have frequently engaged in screen sharing sessions on Saturday mornings with forum member Pandiani, offering assistance with his control issues dating back to his college days. I guided him through his master's degree studies, and now he oversees control operations for power plants in Tuzla, Bosnia. Pandiani purchased Mathcad and follows my content on the Peter Ponders PID YouTube channel. Addressing a technical aspect, while the integrals and discrete jerk function may present challenges, they represent the same system and form the basis of the 17 equations. The issue lies in how to generate these 17 equations. As mentioned earlier, only Cheeco's 3rd order target generator has successfully passed my tests.
Peter Nachtwey posed the question: How can one develop the 17 equations required for this task? To do so, meticulous record-keeping is essential.
Are you familiar with RMCLink, a versatile .NET assembly that enables programming of the RMC using popular languages like Excel, C, Visual Basic, and Python? I have personally utilized RMC Link on a machine interfacing with the RMC controller. While there currently is no direct method in .NET for adding or omitting steps in an RMC program, it would be advantageous for Delta to consider adding this capability to their RMC Link library. Though a workaround exists, it may not fully meet the desired functionality.
According to Peter Nachtwey, it is crucial to ensure that the INITIAL jerk is positive when moving in a positive direction. Does this apply solely to a full 7- or 5-segment move? I previously believed that simply changing the signs would be an easy fix for dealing with a negative initial jerk.
According to drbitboy, full 7- or 5-segment moves are necessary. Changing signs may not be a simple fix for dealing with negative initial jerk. Short moves only need 3 segments. An image .png displays the various cases a 3rd order motion target generator must address for completeness. Identifying the relevant case is key to solving the current situation effectively.
Peter Nachtwey mentioned that short movements typically consist of only 3 segments. However, it is possible for a very brief movement to require only one segment. Regarding the rule stating that the initial jerk should always be in the direction of the movement (assuming a positive move from Pinitial to Pfinal), this applies to various types of moves. These include 7-segment moves (+J,0,-J,0,-J,0,+J), 5-segment moves (+J,0,-J,0,+J), and 3-segment moves (+J,-J,+J). While this rule may not seem universally applicable, especially when considering different initial and final PVAs, I have yet to find a case that contradicts it.
Thomas_v2 mentioned utilizing Heron's method for square roots and 3D map interpolation on an affordable controller. He shared the strategy of using a lookup table with 1024 entries for square roots and scaling up inputs and outputs by factors of 4 and 2 through bit shifting for inputs greater than 1024. Despite the use of integer arithmetic, the encoder remains integer-based.
drbitboy explained that the principle of the initial jerk aligning with the direction of movement is rooted in calculus, where the second derivative always points in the same direction. This concept applies to distance and acceleration as well - to move a positive distance, one must start with a positive acceleration. In the case of positive velocity, an initial positive jerk is necessary. When already in motion, such as tracing a profile with negative acceleration and velocity, the introduction of a more positive segment results in a positive addition to the existing negative values of velocity and acceleration, causing the jerk to become positive.
In a discussion, salbayeng mentioned that understanding calculus is essential, especially when dealing with the second derivative. The direction of the second derivative can determine a lot in a given scenario. For instance, if we consider the second derivative of position over time, what happens when the initial and final acceleration have opposite signs? Additionally, when discussing positive velocity and jerk, clarity is crucial. It becomes even more intricate when factoring in motion, such as tracing a profile. Does this mean that the rules only apply to straightforward cases and not universally? Effective communication is key to resolving misunderstandings in complex topics like these.
What are the key principles being discussed here? There is a fundamental rule that reigns supreme - the Lyapunov function. This rule for stability, attributed to Lyapunov, acts as a guide to assess the accuracy of errors in position, velocity, and acceleration. By analyzing these errors, adjustments can be made to ensure convergence with minimal error. However, the explanations surrounding the Lyapunov function can be quite complex, with even the Wolfram example falling short. This technique may appear baffling at first, leaving many scratching their heads. For instance, a PLC has the capability to create a 7-segment motion profile, but the challenge lies in understanding how to implement this feature within the forum community. With no clear solution in sight after three weeks of discussion, the easier and more cost-effective option may be to invest in a motion controller.
Peter Nachtwey mentioned that the solution to reaching Vmax and Amax has not been discovered by anyone on the forum yet, but not everyone has attempted. A solution for this simple problem has been provided, focusing on understanding the terms involved. Nachtwey also suggested that after 3 weeks, it may be more cost-effective to purchase a motion controller, but perhaps not as engaging.
Peter Nachtwey pointed out the lack of solutions on this forum for calculating motion profiles. It appears I will be the one to inquire: How long will you continue to endure the embarrassment of pretending that calculating motion profiles is a challenging task?
In a forum post, jhenson29 questioned the difficulty of calculating motion profiles and challenged the idea that it is easy. With 17 equations and 17 unknowns for just one scenario, it is clear that this task is anything but simple. Are you up for the challenge of mastering motion profiles with multiple complex cases to solve? Let's dive in and explore the intricacies together.
Peter Nachtwey mentioned that there are numerous scenarios that one must consider. It is important to improve on generalizing when it comes to adding integers. On this forum, no one has successfully demonstrated the ability to add integers, except for myself and one other individual. While it may be easy to add 1, encountering numbers like 3 or negative integers presents a challenge. There are countless cases to consider when adding integers. Can you solve all of them?
User jhenson29 commented that improvement is needed in generalizing skills. Have you viewed the .png file provided? Each case shown is unique, making it suitable for diverse scenarios.
Peter Nachtwey expressed his thoughts by stating that this criteria applies to a wide range of cases. However, have you considered whether your .png file accounts for all possible scenarios, including the case of a 7? Take a moment to ponder this and see if you can anticipate the direction I am heading in.
User jhenson29 inquired about the capability of a .png file to handle all cases, including a case involving the number 7. The mentioned .png files, such as seg1234567 and seg123567, cater to different scenarios where segments are utilized differently. The process also factors in peak velocity calculation, real-time adjustments, and reversing motion sequences. To delve deeper into these concepts, refer to this insightful discussion on PLCTalk forum: http://www.plctalk.net/qanda/showthread.php?t=119883. Discover a straightforward solution to these complex motion control scenarios.
Peter Nachtwey mentioned the presence of a file named seg1234567 that handles scenarios involving all 7 segments being used. Another file, seg123567, deals with cases where the commanded velocity is not achieved, resulting in no constant velocity segment. In such instances, determining the peak velocity attained can be challenging. It seems you may have misunderstood the query. The focus was not on 7 segments but on the numerical value 7 as an input. To clarify, calculations do not segregate data based on individual segment time spans or different numeric inputs; instead, a unified approach is adopted. Consider the possibility of developing a single abstraction capable of computing targets for any input value. This emphasizes the importance of enhancing generalization skills and minimizing the reliance on specific "cases" for calculation purposes.
User jhenson29 expressed confusion about the initial response, emphasizing that the query was not about 7 segments but rather about utilizing the number 7 as an input parameter. The user seeks clarity on how to handle parameters like position, velocity, and acceleration when the mind is unclear. To simplify, the user suggests starting with a comprehensive understanding of the issue at hand. The user highlights the ability to create a universal abstraction capable of calculating various targets based on any input. This concept prompts the user to inquire about the definition and demonstration of an abstraction. The user advocates for improved generalization skills and mocks the notion of segregating different scenarios into separate cases.
In a forum discussion, jhenson29 expressed interest in understanding the specifics of what the original poster (OP) is aiming to achieve. Recognizing their expertise in the topic, a question was posed regarding designing S-curve motion profiles for a rapid camera slider. The slider covers a 4-meter distance in under 1 second and is equipped with pan and tilt heads driven by stepper motors controlled by Arduino. Parameters such as time, acceleration, and distance are predetermined before the motion begins. Can S-curve motion profiles be implemented in this setup?
To calculate the symmetrical slide time for the given inputs, the formula calculated as follows: Abs(a) - constSymmetricalslidetime = 1 sx_0.5 = 4 / 2t_0.5 = 1 / 2a = 2*x_0.5 / t_0.5 ^2 = 2 * (4/2) / (½)^0.5 = 4 / 0.25 = 16V_0.5 = a * t_0.5 = 16 * 0.5 = 8x_0.5 = x / 2 = 4 / 2 = 2t< 0.5x = 8 * t^2t> 0.5x = 2 + 8*(t-0.5) – 8 * (t-0.5)^2. It is important to note that while this solution may not be entirely satisfactory, it is the best that can be achieved given the available input data.
In a recent discussion, MaxK shared a formula for calculating acceleration with symmetrical slide time. This formula involves various variables such as a, constSymmetricalslidetime, sx_0.5, t_0.5, and V_0.5. The calculated value of acceleration is 16 when using the given input data. Even though the solution provided may not be completely satisfactory due to the lack of sufficient input data, it still serves as a helpful guide. It seems that the scenario involves constant acceleration. How can one further enhance the acceleration curve for added smoothness? Your assistance is greatly appreciated in improving the accuracy of these calculations. Thank you for your insights!
Henry_ inquired if the acceleration provided has a constant rate and asked how to incorporate smoothing into the acceleration curve. MaxK calculated the linear acceleration rate for both ramping up and ramping down, but did not offer a suitable polynomial for achieving a smooth s-curve. An ideal s-curve should start and end with zero acceleration during ramp up and ramp down. With a constant acceleration rate of 16 m/s^2, the peak acceleration during ramp up would be around 24 m/s^2. It's worth considering if the system can handle such rapid acceleration, which is over 2.3g. Additionally, MaxK determined a peak speed of 8 m/s, prompting the question of whether the motor can handle this speed. Ensure to assess whether the system will be limited by speed or acceleration. The camera system's mass will also play a role in the design process. Once the system design is finalized, it's recommended to invest in a quality motion controller. While 7 segment motion control is a viable option, it may introduce complexities that can be avoided by customizing the motion segments to prevent rounding errors. For example, consider if a segment takes 66.66 milliseconds but the PLC can only scan at 1 millisecond intervals. This discrepancy could lead to significant errors in both time and distance.
It has been nearly two years since the inception of this discussion. Has anyone successfully implemented a 7-segment motion profile using a PLC? Surprisingly, the 17 formulas required for this task have not yet been shared. I mentioned previously that the S7-1500 PLC already includes this functionality, but no one has reported achieving a 7-segment motion profile using ladder logic or ST programming yet. Why is that? Creating 7-segment motion profiles is a complex process, leading many to opt for purchasing a motion controller instead. Interestingly, the older RMC100 model utilized cosine ramps for motion control. I have previously shared instructions on how to create a simple 3rd order ramp on this forum. In this scenario, the acceleration is not equal to zero at the start and end of the ramp, while the position and velocity are specified.
Primary school math can be a fun exercise in solving equations. When calculating the position of an object over time, understanding the various orders of acceleration is crucial. In the case of symmetrical accelerations and decelerations, the equations become more straightforward to solve. For example, when analyzing the motion of an object with varying accelerations, such as in the provided equations, it is important to consider the symmetry between acceleration and deceleration. By calculating the position of the object at different time points, such as at 0.25 seconds or 0.75 seconds, we can see how the acceleration and deceleration affect its movement. However, if the requirements and limitations of the system are more complex, such as the need to recalculate curves dynamically or adhere to speed restrictions, then it may be worth considering investing in a motion controller. This can help simplify the process and ensure accurate results, especially when dealing with non-symmetrical acceleration patterns. In conclusion, while solving equations for motion can be challenging, understanding the specific requirements and limitations of the system is crucial. By considering all factors and potentially utilizing a motion controller, you can achieve more accurate and efficient results in analyzing object motion.
Peter Nachtwey inquired whether anyone has successfully implemented a 7-segment motion profile on a PLC. As of now, the 17 necessary formulas have not been developed. While this has not been achieved by anyone yet, it remains a priority on my task list.
In a nutshell, MaxK discussed a basic math concept involving primary school level equations. The formula involves calculating the position (x) at different points in time (t) using acceleration and deceleration. The solution provided is for a 3rd order equation, where accelerations and decelerations are symmetrical. The calculations show how to determine the position based on specified accelerations and decelerations within specific time intervals. The formula is broken down into segments based on different time intervals (0-0.25, 0.25-0.75, etc.) to accurately compute the position at each point. Ultimately, the discussion emphasizes the importance of understanding system limitations and requirements before designing any motion control system. It highlights the need for precise calculations and considerations to avoid costly mistakes in the design process.
drbitboy mentioned that although it's not a priority for him right now, it's definitely on his to-do list. He is eagerly anticipating the completion of the task. When dealing with a 7-segment profile, the challenge lies in managing the acceleration, velocity, and speed limits, especially when the movement is extensive.
Peter Nachtwey mentioned that he is patiently waiting for the 7-segment profile, especially when the move is extended, and the acceleration, velocity, and speed constraints are met. However, he finds the segments with zero or negative duration to be more intriguing and challenging.
Peter Nachtwey mentioned waiting for the 7-segment profile to reach its acceleration, velocity, and speed limits during long moves. Drbitboy also noted that segments with zero or negative durations pose an interesting challenge. Is this related to a 3rd order system with constraints? Let's steer clear of mathematics for now. There appears to be a technical and commercial dilemma here: for less critical systems without strict time and accuracy requirements, simplified solutions can be devised. However, for precise solutions, PN likely has the answers. It's doubtful that others will code the published mathematics, and motion controllers may be the best option for exact control requirements. Why is PN creating competition for his colleagues in this aspect?
For more than two decades, I have been equipped with the expertise needed for motion control projects, dating back to the development days of the RMC75. In the earlier version, RMC100, cosine ramps were utilized. The complex nature of these projects involves solving a set of 17 equations with 17 unknowns. When approached with a new project, I inquire about the specifics such as mass, speed, and duration of the motion. By utilizing Mathcad worksheets, I can swiftly determine the necessary requirements. I have formulas readily available that cater to motion profiles involving acceleration, deceleration, and constant velocity in equal thirds of time. The calculated velocity formula (velocity=(3*Δx)/(2*Δt)) and acceleration formula (acceleration = (9*Δx)/(2*Δt^2)) assume linear ramps rather than S-shaped ramps. For S-ramps, peak acceleration is around 1.5 times the average acceleration. The complexity of motion generation involving 7 segments is highlighted in my directory of work files. Out of various segment combinations, the "seg1234567" combination is typically sufficient. Managing the PID control in comparison is a simpler task.
My extensive knowledge spans from the beginning of the universe, even before the singularity. I possess wisdom that surpasses mortal understanding, which was revealed to me through 17 sacred tablets and 17 secret runes. Among the truths I have uncovered are the fact that a triangle has 3 angles and a square has 4 corners. However, when it comes to a circle (or possibly an ellipse), my calculations diverge from those of others. My wisdom delves into various topics, including the relationships between angles in geometric shapes and the mysteries of the universe. Contained within my vast repository of wisdom are insights into global intelligence services, the Masonic conspiracy, and the reptilian conspiracy. However, one question remains unanswered: What has become of PN's self-criticism and humility? In comparison, all other inquiries and opinions pale in significance. This serves as a reminder of the futility of attempting to engage with PN on any level.
It appears that you may be feeling bitter. If you're interested, I can show you my collection of documented bugs that I encountered on my journey. I came across numerous issues and successfully addressed them. I have a knack for identifying challenges in achieving certain goals, especially when it comes to high speeds and accelerations. I have been able to save clients a significant amount of money by highlighting potential difficulties early on. While some tasks may be feasible, the associated costs may be prohibitive. In the context of the customer's requirements, cosine ramps offer a simple solution compared to complex 3 segment 3rd order ramps. The limitations of old technology, such as the RMC100's 80186 processor without floating point capability, made the use of polynomials impossible. Despite raising this concern earlier, it went unheeded.
@MaxK....I must disagree! Some time ago, I conducted a search for an s-curve which led me to Pete's highly effective program that I successfully implemented on an RPi-Pico using interpreted BASIC. The Trapezoidal function was not as smooth as I desired, but now I have a 1Khz PID and trajectory generator operating on a mere $10 MCU, complemented by a $5 quad-decoder/counter (LS7366) and a $5 12-bit DAC. This solution runs on a self-hosted, open-source BASIC interpreter at zero cost.....Simply magnificent! No need for overpriced PLC software that becomes useless once the license expires. Many thanks to Pete for this amazing solution. And let's not forget the impressive 64bit position range and the astonishing 40M quad counts per second speed.
@Tinine, was that the ramp fraction version you were referring to? The formula for calculating velocity during ramping up is x(f) = ramp_dist * (3*f^2 - 2*f^3) + x(0), where f represents the fraction of the ramp time. And for ramping down, the formula is x(f) = x(1) - ramp_dist * (1 - 3*f^2 + 2*f^3). These calculations work effectively for both positions and velocities, with the option to derive velocity from the equations. Additionally, there is a fifth order version available where accelerations start and end at 0 during the ramps. It's worth noting that the speed and acceleration capabilities of the motor do not affect the accuracy of these calculations. Unfortunately, there has been no response from the original poster regarding this matter.
Indeed, that particular solution works wonderfully. However, it is essential for the motor to have the ability to move and accelerate rapidly for optimal performance. Unfortunately, there was no response from the original poster regarding this issue. I am aware that the same principle applies to extremely high rates of PID sampling. From my experience, I have found that lower sampling rates (500Hz) are easier to tune in certain scenarios without sacrificing performance.
Hey @Peter Nachtwey! It's been a while since I last looked at this, but I noticed that my code seems to be more straightforward than yours. In my original test routine, I declared variables such as res, samptime, f, intspeed, ramp_segments, and frac. I set ramp_segments to 1/1000 and initialized res to 1000 for synchronization purposes. By incrementing samptime by 1 each time, I was able to achieve 1ms determinism. Using calculations involving frac and f, I determined intspeed and printed the results. The loop continued until samptime exceeded res.
Tinine expressed curiosity to Peter Nachtwey about the simplicity of their test routine in comparison to his. The coefficients and functions used were similar, with the main difference being the inclusion of starting and stopping points. Tinine suggested the addition of LaTeX, possibly through MathJax, for better representation of mathematical equations.
@Peter Nachtwey, I'm not sure what you meant in the last part of your message, but your elegant solution has helped me save a significant amount of money. I plan to semi-mass-produce this product. Thank you!
Tinine expressed her disagreement with MaxK by saying that it was unfair. She questioned if he was trying to shame, judge, or punish her. The complexity of knowledge can sometimes lead to confusion. Do you understand why the formula "3*f^2-2*f^3" works in a certain way? The spoiler reveals the equation for the calculation.
MaxK expressed feelings of discouragement, suggesting a lack of understanding of complex mathematical formulas. Rather than attempting to shame or judge, he acknowledges his role as a hardworking individual focused on delivering product successfully. Admitting to seeking help when needed, he emphasizes the value of research and professional assistance. Despite watching instructional videos on YouTube, MaxK still struggles with comprehension, opting to read online threads for knowledge as opposed to watching television.
An old discussion resurfaces with a common question that arises periodically. However, the solution remains the same and I have all the answers to it. Despite being labeled as arrogant by JRW, my expertise in hydraulic motion control, modeling, and testing has been recognized by IEEE.org and I am a part of the Intentional Fluid Power Society hall of fame. With over 40 years of experience in selling motion controllers, I possess profound knowledge that remains timeless. I have a proven method showcased in an example [eg1234567] where I calculate velocity and acceleration based on the user's desire to move 4 meters in 1 second. Key parameters such as mass, distance, and speed play a crucial role in the success of any project. By addressing these aspects, I have helped customers avoid costly mistakes and impractical ventures. Although a fast PLC may have the capability to run complex formulas, it may struggle to achieve the desired acceleration in a short distance move. This challenging scenario, aptly named the "problem from hell," has been tackled by forum member cheeco and myself, distinguishing us as experts in the field. I have been in correspondence with Robert Lewis from Fordham University, who acknowledged the complexity and intricacies of motion controller mathematics. My extensive experience has equipped me with algorithms that could enhance PLC performance, yet I refrain from sharing them to maintain the integrity of standard motion control sales. As for drbitboy and MaxK, I invite them to grasp the complexity involved in solving 19 unknowns with 19 equations, including the calculation of jerk in motion profiles. After four decades of mastering motion control, I am astounded by the oversimplification of tasks in the industry.
Peter Nachtwey stated that he didn't want to wait years for someone else to figure it out, so he decided to share a straightforward example, like "eg1234567". He appreciates the offer to expand, but prefers to figure it out independently when he can make time to focus, rather than getting distracted by playing pubg.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Solve Your Operational Challenges with Oxmaint → Get Free Demo
Answer: - An S-curve motion profile consists of smooth acceleration and deceleration phases, resulting in reduced stress on the motor and mechanical components. It provides a more controlled and precise motion compared to linear ramping.
Answer: - A 7-segment S-curve motion profile typically consists of 6 segments for acceleration and deceleration, with a constant velocity segment in between.
Answer: - The equations for each segment of the S-curve motion profile can be derived based on the desired acceleration, deceleration, and velocity profiles. Utilizing mathematical formulas and motion control principles can help in determining the equations for each segment.
Answer: - Yes, a PLC can be programmed to implement S-curve ramping for precise control over the timing of reaching a setpoint. By adjusting the parameters and equations within the PLC program, the desired time frame for reaching the setpoint can be achieved consistently.
Answer: - To implement S-curve ramping with a Siemens G120 drive using a PLC, you will
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.