Optimizing RSLogix for Position Register Latency on Kinetix 5100 Servo Drive

Question:

I apologize for the lack of clarity in the title. The scenario involves utilizing RSLogix to configure and trigger position registers on a Kinetix 5100 servo drive. While my program is functional, I am concerned about the latency between triggering a position register and the drive receiving the command. Currently, I am using message instructions for setting and getting attributes. Initially, I placed these instructions at the beginning of the routine, but encountered issues with JMP and LBL instructions. Considering organizing the MSG instructions in a separate routine and using JSR for writing or reading parameters. Seeking advice on optimizing this process without overcomplicating it.

Top Replies

Are you in need of specific commands or data that require the use of MSGs? This method of instruction can be slow and asynchronous compared to the scan. In most cases, tasks can be accomplished using direct tags and motion instructions, while necessary data can be configured as cyclic parameter updates within the axis. The timing of execution depends on the specific application. For optimal speed, consider utilizing motion event tasks with axis updates set to 5ms. However, be mindful of task overrun. Otherwise, utilize a periodic task for other tasks.

This is a standalone drive that does not support motion axis and an outdated version of logic that does not support AOP for implicit messaging. My available options include explicit messaging for hardwired inputs and outputs. I am currently considering both options. While I am likely to choose hardwired inputs and outputs for my PLC due to their lower resource cost, I still have a theoretical question regarding this decision.

Robertmee mentioned that to achieve optimal speed, they utilize motion event tasks. I had overlooked the concept of event tasks before, but upon further exploration, I realized their efficiency. While initially hesitating about creating a task for a single device, I now understand that the controller is not concerned with the number of tasks. Event tasks appear to be highly efficient in enhancing speed and performance.

In a recent forum post, user patrickmoneyy shared their initial hesitation towards utilizing event tasks, as they had never used them before. They questioned the efficiency of creating a task for just one device, but ultimately realized that the number of tasks didn't actually matter to the controller. It turns out that event tasks are surprisingly efficient, with a maximum of 32 tasks allowed. This brings up the question: what exactly makes event tasks more efficient than other options available? Let's dive into the details.

JeremyM questioned what factors contribute to the effectiveness of an event. It is possible that the initial statement was not well articulated. Perhaps it would have been more precise to mention how an event can be more effective than continually scanning a routine if it only needs to be triggered every few seconds. However, the difference in efficiency is likely minimal. One advantage of event tasks is their ability to interrupt other tasks to execute, which aligns with the original goal of reducing latency on the explicit message index trigger. Considering event tasks as a viable option is worth exploring. It was noted that the efficiency statement was overly broad, and there was a oversight in not checking the maximum number of tasks allowed. It is important to consider the number of tasks as the controller does take this into account. Thank you for the clarification.

Your strategy of moving the MSG instructions into a separate routine and using JSR for writing or reading parameters could work well, it might indeed reduce some of that latency. Don't forget to test this thoroughly, though. You could also consider using Produced/Consumed tags if both controllers are on the same network. It's a bit more complex to set up initially, but it significantly reduces the latency in communication between controllers. Additionally, consider splitting your routine workloads into smaller, more digestible sections. This could facilitate execution without compromising on efficiency or leading to more JMP and LBL confusion.

You're on the right track considering a separate routine for your message instructions. The separation can indeed reduce the latency because the rest of your routine wouldn't wait for your MSG instructions. I also urge you to check the status of your MSG instructions before executing the next move. Remember, RSLogix tends to follow a top-down approach; the execution begins at the top and moves downwards. By structuring your routines correctly, you can avoid problems associated with JMP and LBL statements and ensure smoother operation. Also, consider using periodic tasks instead of continuous ones if latency is an issue. Periodic tasks give you more control over execution timing and can reduce latency. Keep it simple and you'll have a more efficient and maintainable code in the end.

It sounds like you're on the right track thinking about separating your MSG instructions into a dedicated routine and using JSR to streamline the process. This could help minimize congestion in your main loop and reduce latency since the MSG instructions would run independently without interfering with the critical timing of your position control logic. Additionally, consider implementing a flag to check if your messaging functions have completed before proceeding with your position commands, which might help in managing the flow and ensuring that commands are executed in the correct sequence. Keeping your code organized will definitely aid in troubleshooting and future modifications too!

More Replies →

Streamline Your Asset Management
See How Oxmaint Works!!

✅   Work Order Management

✅   Asset Tracking

✅   Preventive Maintenance

✅   Inspection Report

We have received your information. We will share Schedule Demo details on your Mail Id.

To add a comment, please sign in or register if you haven't already..   

Frequently Asked Questions (FAQ)

FAQ: 1. How can I optimize the latency of position register commands on a Kinetix 5100 servo drive using RSLogix?

Answer: One approach to optimize the latency is by organizing message (MSG) instructions in a separate routine and using Jump to Subroutine (JSR) for writing or reading parameters. This can help streamline the communication process without overcomplicating it.

FAQ: 2. What are the potential issues with using JMP and LBL instructions in conjunction with MSG instructions for setting and getting attributes in RSLogix?

Answer: Placing MSG instructions alongside JMP and LBL instructions in the same routine can sometimes lead to complications and issues. To avoid this, consider segregating MSG instructions into a separate routine for better organization and efficiency.

FAQ: 3. How can I address concerns about the latency between triggering a position register and the Kinetix 5100 servo drive receiving the command in RSLogix?

Answer: By optimizing the placement and execution of MSG instructions, along with utilizing JSR for parameter operations, you can work towards minimizing the latency and improving the synchronization between triggering position registers and the drive receiving commands.

Ready to Simplify Maintenance?

Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.

Request Demo  â†’