Indeed, their gateway rack includes a CPU that I could potentially utilize. It was initially marketed to them as a boiler optimization package, but it has been ineffective and is now largely idle. They currently operate three boilers, alongside a fourth PLC-5 that manages "balance of plant" auxiliary systems. The gateway machine was designed to fine-tune the adjustments typically handled by operators across the three boilers for enhanced energy efficiency. However, it caused excessive fluctuations and failed to deliver the expected results, leading them to disable its control functions for the past year. By integrating fragments of my code into this system for experimentation, I can avoid the need to install new equipment on a wall and make connections. All I require are the existing analog input values, conveniently located in a 16-word block that I can access using a single MSG instruction, allowing me to map them to my new logic data tags efficiently.
Although it consists of just 27 pages in PDF format, this resource resembles a pamphlet rather than a traditional book. Nevertheless, I am including it in my curated collection of simplified control theory materials, which I share with our junior engineers for their professional development.
I've been extremely busy lately, so I can't provide a detailed explanation. However, the main concept is to have the ControlLogix (CLX) system read the same process variable (PV) signal as the PLC-5. From there, you can implement your best estimation of how you'd like the new PID controller in the CLX to be configured. Next, use the CLX to visualize the control variable (CV) output signals from both the existing and the new PID controllers on the same graph. This approach eliminates the need for system modeling since you will be utilizing the actual data during the tuning process.
Feel free to experiment with the new PID configuration as you strive to replicate its response by overlaying the CV output signals. Keep in mind that the CV from the new CLX setup isn't actively controlling anything at this stage—it's simply a placeholder input for trend comparison. This allows you to assess how the new system responds against the old signal. With some patience and time, you should be able to prepare the new CLX controller for seamless integration into the system, ensuring the PID tuning returns to its original state prior to any modifications.
**Update:** The concept of running both processors side by side to compare PID behaviors is truly innovative. Thank you for your acknowledgment! I believe I suggested it previously on a forum, but I'm currently unable to locate that thread. I’m confident Ken remembers the idea, as he seemed to grasp my intent behind the initial questions. Best of luck with your project, and I wish I had more time to dive into this!
Ron Beaufort mentioned, "I’m currently overwhelmed with tasks, so I can’t provide a detailed explanation right now. However, the primary concept involves configuring the ControlLogix (CLX) to read the same process variable (PV) signal that the PLC-5 is monitoring. From there, you’ll input your best estimate of how you’d like the new PID (Proportional-Integral-Derivative) controller in the CLX to function. This setup allows you to visualize the control variable (CV) output from both the existing and the new PID configurations on a single graph.
This method eliminates the need to 'model' your system, as you are working with actual, real-time data during the tuning process. You can freely adjust the new PID setup while trying to replicate its response and overlay the CV output signals. It’s important to note that, for the moment, the CV from the new CLX setup doesn’t actively control any processes. It serves as a 'dummy' input on the trend, enabling you to compare the old system's response with the new one.
With sufficient patience and time, you should be able to integrate the new CLX control system back into your operations and hopefully return to the baseline performance you had prior to implementing any changes. Click to expand… Excellent! I’m fully in favor of this approach. Installing new equipment with streamlined, properly programmed logic significantly enhances our chances for precise fine-tuning, ultimately leading to improved system performance. Thank you, Ron and Ken!"
Why hasn’t anyone developed a simulation for a First-Order Plus Dead Time (FOPDT) and Second-Order Plus Dead Time (SOPDT) temperature system using an Analog Output Interface (AOI)? I’m ready to assist with the necessary formulas if someone can create the AOI. This task shouldn’t be overly complicated. However, users must understand essential parameters such as open-loop gain, time constants, and dead time to effectively utilize the system.
- 29-03-2025
- Peter Nachtwey
To enhance the performance consistency between your active and test controllers, consider the following recommendations. Inconsistencies in loop update periods or scan times can significantly impact the integral and derivative components of your PID controller. Since derivative action is not being utilized, your primary focus should be on adjusting the integral gain. The specific adjustments required will depend on the chosen PID equation.
Ensure that you are employing the same type of PID equation, whether it's ISA-dependent or AB-independent. For a comprehensive explanation, refer to the insights shared by Mr. Beaufort and others at this link: [PLC Talk Forum](http://www.plctalk.net/qanda/showthread.php?t=18123). If you are using independent gains, remember to multiply the current Ki by 10 to account for scanning the loop 10 times slower. Conversely, if you are following the ISA-dependent PID equation, simply divide Ti by 10.
Proportional gain adjustments are not necessary due to variations in scan time, but they are influenced by the input scaling. It's crucial that the error calculations, expressed in percentage, remain uniform across both systems. This consistency hinges on the primary variable (PV) engineering units min/max values producing identical percentage errors on both controllers. With the PLC-5 analog system being 12-bit, scaling is typically based on the range of 0-4095. Therefore, ensure that the new engineering and input span configurations yield results equivalent to those of the PLC-5 (refer to parameters: .MAXS, .MINS, .MAXI, .MINI).
Additionally, verify that the translation process has accurately determined the correct loop "direction." Specifically, confirm that the error calculations (set point (SP) - process variable (PV) or PV - SP) are aligned on both systems. Post-loop computations concerning control variable (CV) must consider the implicit 0-4095 scaling relative to the 0-100% PID output. This conversion should have been addressed in the logic translation; however, ensure that any computations receiving the PID output as input harmonize with the 0-4095 scaling.
While a slower loop update time of 200 ms compared to ~20 ms might have an effect, it is unlikely to significantly impact applications like boiler control, especially if the original analog inputs were not updating at a high frequency. However, during your side-by-side testing, it's vital to keep your input messaging strategy from becoming too sluggish. Ideally, aim for input updates every 200 ms, provided network conditions permit this frequency. The discussion on DH+ message paths through a gateway has been elaborated upon in other forums.
By implementing these strategies, you can optimize your controller’s performance and maintain a high degree of accuracy in your testing processes.
Thank you for sharing those valuable insights regarding the factors influencing gains, particularly in relation to varying execution rates and update time configurations. Your analysis of dependent and independent variables, as well as the impact of error and action polarity, is truly impressive!
Mispeld stated: Here are several recommendations to help achieve consistent performance between the active and test controllers rapidly. Inconsistencies in loop update periods or scan times can influence the integral and derivative components of the control system. Given that a derivative is not involved, your primary focus should be on the integral gain. The impact of these parameters will vary based on the selected PID equation, so it is crucial to ensure you are using either the ISA (dependent) or AB (independent) PID configuration. For additional insights, refer to Mr. Beaufort’s comments and more detailed explanations found here: http://www.plctalk.net/qanda/showthread.php?t=18123.
If you are utilizing independent gains, you'll need to multiply the current Ki value by 10 to compensate for the slower loop scan time, which is running at 10 times less frequency. Conversely, if your PID equation is ISA/dependent, simply divide Ti by 10 to adjust accordingly.
Thank you for the valuable information. All PID blocks in my current setup utilize independent gains, with an update frequency of 0.2 seconds. However, they are processed roughly every 20 milliseconds (with one exception), meaning that if I modify the loop update time in the new system to align with this 20ms periodic rate, I will indeed need to reduce the integral gain by a factor of ten to optimize performance.
Note that the Proportional gain does not require adjustments for scan time variations, but its effectiveness is influenced by input scaling. It’s essential to maintain consistent error calculations—expressed as percentages—between both systems. This consistency relies on ensuring that the Process Variable (PV) engineering unit's minimum and maximum values generate identical percent errors across both setups. Since the PLC-5 analog operates on a 12-bit scale from 0 to 4095, it's critical to verify that the new engineering span and input span produce equivalent results to those of the PLC-5 (refer to .MAXS, .MINS, .MAXI, and .MINI for more information).
I maintained the same scaling parameters, transitioning to real numbers ranging from 0.0 to 4095. The PLC-5 did not utilize Controlled Variable (CV) scaling, which initially resulted in zeros for CV Max and Min in the new PID blocks, but this issue has since been identified and rectified. Preserving consistent scaling will facilitate a smoother transition for technicians and operators familiar with these ranges. Furthermore, I integrated an Add-On Instruction (AOI) to "CLAMP" the analog inputs, which confines the resultant PV tags within this range, as the PLC-5 automatically adjusted these when set for 4 to 20mA and 12-bit. The 1756-IF16 does not perform this adjustment natively, so I ensured that new tags are created to fully utilize the card's capabilities, allowing for real-time display in milliamps during commissioning and calibration checks.
It's important to double-check the translated loop "direction" selection—specifically, ensuring that the error calculation (setpoint - PV) or (PV - setpoint) is consistent across both systems. Additionally, be aware that post-loop calculations on the CV need to accommodate the implicit scaling from a 0 - 4095 range corresponding to a 0 - 100% PID output. The logic translation should account for this, and any computations using CV as input will require accepting the 0 - 4095 range.
While there could be some influence from the slower loop update times of 200ms versus ~20ms, this may not significantly impact applications like boiler control, as the analog inputs may not have updated rapidly in the original setup. Nevertheless, in side-by-side testing, it’s critical to ensure that your messaging strategy remains responsive, ideally providing updates every 200ms (the new loop update) if network conditions permit.
Based on my review, the conversion appears spot on in terms of equation selection, directional consistency, and PV tracking. Since the PLC-5 did not employ CV limiting, these values were initially translated as zeros for CV Scaling Max and Min, but this has been corrected. Several programs do manage output limits, and these settings seem accurate as well.
Your observations regarding messaging rates are insightful. The original code employed a self-repeating timer to initiate a BTR command every 200ms in order to read from the analog card and execute a subroutine featuring one PID block. The remaining PID blocks run continuously at every scan (~20ms) and all utilize independent equations. I am unsure why this particular approach was taken; it seems like an oversight.
Therefore, I believe I can implement a message to read those tags every 200ms, although achieving a 20ms interval may prove challenging. I might need to reach a compromise, but understanding the results and determining the scale factors necessary for adjusting the integral gain during this real conversion is critical information.
OkiePC commented: "Thanks for the valuable information. All the PID blocks utilize independent gain settings and are configured with an update interval of 0.2 seconds. However, they are processed at a speed of approximately 20 milliseconds, with one exception. Therefore, if I adjust the loop update time in the new system to align with my 20ms (0.02 seconds) periodic rate, I should divide the integral gain (I gain) by ten to maintain optimal performance, correct?"
To elaborate, considering the independent gains and accurately defined loop update time, I should actually multiply the integral gain (Ki) by 10. Here’s my rationale: In the PLC-5 system, the loop was set to an update time of 0.2 seconds. Consequently, when integrating (summing) the error, it multiplied the error by that 200 ms interval prior to summation. However, during that process, the actual operation was occurring ten times faster at the 20 ms scan rate. Essentially, this indicates a 10x increase in the integral gain. Once you adjust the loop update time setting, you’ll need to transfer this "artificial" 10x factor into the gain itself to achieve the same response characteristics. This adjustment is applicable regardless of the specific update time, as long as it is correctly defined within the PID block settings.
I believe I can implement a message (MSG) to read those tags every 200 milliseconds; achieving this every 20 milliseconds may be more challenging. For those who have the budget and a valid reason to invest, the 1756-RIO module offers a unique "ghost mode." This feature enables it to monitor RIO I/O and perform Block Transfers without impacting the scan time or addressing within a RIO network. Unlike the previous multipurpose 1756-DHRIO, the 1756-RIO is a specialized Allen-Bradley Remote I/O scanning engine, developed by QTS in Florida. Its network-oriented counterpart, the "AN-X," is distributed and supported by ProSoft, and it offers similar functionalities.
This enhanced approach should improve clarity, uniqueness, and search engine optimization (SEO) while maintaining the core message.
Mispeld stated, "Considering the independent gains and the accurately specified loop update time, it's advisable to increase the integral gain, Ki, by a factor of 10. My reasoning is based on the PLC-5's configuration, which indicated an update time of 0.2 seconds. During the integration phase, this meant that the error was being multiplied by a 200 ms interval before accumulation. However, the actual operation was occurring 10 times faster at a 20 ms scan rate. Essentially, this results in a 10-fold increase in integral gain. Once you adjust the loop update time parameter, it's crucial to incorporate this 'artificial' 10x factor directly into the gain to maintain the desired response. This adjustment holds true regardless of the actual update time, as long as it is correctly specified in the PID control block."
Ken Roach added, "If your project allows for it and there's a valid reason to implement one, consider the 1756-RIO module. This module features a 'ghost mode' that enables it to monitor RIO I/O and Block Transfers without impacting the scan time or addressing of the RIO network. It’s worth noting that this is not the original multipurpose 1756-DHRIO. The 1756-RIO is an Allen-Bradley Remote I/O scanning solution developed from hardware and firmware by QTS in Florida. Additionally, there is a network-based variant known as the 'AN-X' which is distributed and supported by ProSoft, offering similar features."
Reflecting on a past experience, I recalled that the customer likely has some ProSoft AN-X modules. A previous integrator attempted to upgrade the PanelView 1200 to a PanelView Plus using these modules to connect to the DH+ network. Unfortunately, the conversion was poorly executed—they rearranged everything, renamed critical elements, and added distracting colorful trends. This led to significant dissatisfaction among the operators due to the subpar response to their inputs, resulting in our team being contracted to redo the setup using a G15. For my HMI connections, I utilized a serial cable to link to the PLC-5 and started with the classic 1980s graphics from the PanelView 1200, which the operators preferred.
In summary, the ProSoft module remains installed and connected within the panel, and I know of two other boilers that also have these modules installed, albeit not connected. Therefore, I'm confident I can borrow one for our purposes. However, I doubt it would allow monitoring of the backplane block transfer from the analog card to the CPU. On the other hand, I might be able to observe the data transfers between the analog rack and the digital rack, which would include the same critical values.
I created a brief simulation where the Loop1 PID instruction operates independently within a task that runs every 200 milliseconds. The loop update interval is configured to 0.2 seconds, with the proportional gain (Kp) set at 0.1 and the integral gain (Igain) at 0.1. Meanwhile, Loop2 is identical to Loop1, but it executes in a 20-millisecond task. In Screen2, I applied the same step change in the setpoint in the opposite direction, but this time, the integral gain for Loop1 is adjusted to 1, which is ten times greater. This setup allows for an in-depth analysis of PID controller performance under varying time constraints and gain settings.