Dalporto explained that the Hn value is not only being directed to the HMI but also to a lookup table. This lookup table is crucial in adjusting the "main" setpoint for a brief moment, allowing the system to respond accordingly. While this adjustment may go unnoticed by most, Dalporto acknowledges the importance of addressing it for optimal performance.
The decision to utilize Energy_Kinematic_Global in this manner is perplexing to Dalporto. Initially, it seemed intentional, but upon further examination, the rationale behind it remains unclear. The unnecessary delay in the scanning process raises concerns as it slows down the system unnecessarily.
Dalporto appreciates the input from fellow colleagues on this matter and will work towards resolving these issues. It is important to note that the scan order plays a significant role in the functionality of the logic utilizing Hn. Despite this, the asynchronous updating of the HMI may still pose challenges.
To mitigate this issue, Dalporto suggests adding a simple command to redirect the Hn value to Hn_HMI after the limiter. By displaying Hn_HMI instead, it can eliminate any discrepancies caused by the asynchronous updates.
dalporto asked for clarification about the rate at which TUR_FT13, TUR_PT15, and TUR_PT16 data fluctuates over time. This can range from rapid changes within milliseconds, to minor fluctuations over a period of time, or consistent values from an HMI system that experience occasional small or significant adjustments throughout the day or hour.
The stability of operations is generally good, with all measurements tied to river elevation. A flatline detection system with a 10-minute timer is in place for reference. In the event of abnormal operation, these values become irrelevant as the unit will trip regardless.
Robertmee pointed out that due to the scan order, any subsequent logic relying on the variable Hn will function properly, as the logic is executed in sequence. The issue arises with the HMI displaying interim values of Hn, which may update independently from the PLC scan. To resolve this, simply add a MOV Hn to Hn_HMI after the limiter to display the updated value on the HMI. I have since redesigned the logic to address this issue and have incorporated another tag. Thank you.
Dalporto mentioned that the Hn value not only goes to the HMI but also feeds into a lookup table that adjusts a "main" setpoint for a brief moment. While this shift may occur in milliseconds and go unnoticed, efforts will be made to address it. The system's logic overlooks this value as a limiting factor, possibly due to the asynchronous nature of HMI updates. Using a limiter is a common strategy to address this issue, especially in Structured Text (ST) programming where IF statements behave differently than ladder logic contacts. By continuously writing to the same variable, breaking the traditional LADs rule, it becomes easier to handle such situations. Various opinions exist on this approach.
To confirm the behavior, consider trending the variable and stepping through the program or setting a trigger to monitor its changes throughout a cycle. If your IDE lacks these features, try creating test variables with R_TRIGs to capture values at each stage for analysis.
This concept is understandable, but it is still perplexing me. If the HMI displays a value of 2.208 at any point, does it indicate that Hn temporarily switches to 2.208 during a scanning process of the calculation line? And then returns to 25 after the limiter lines are scanned? Unfortunately, I don't have the time to conduct a test at the moment, but it definitely seems like an intriguing theory. As mentioned before, I am not very experienced with ST programming, so this anomaly caught my attention based on intuition.
Dalporto expressed confusion about the HMI reading of 2.208, wondering if it meant that Hn effectively changes to 2.208 during a scan before reverting back to 25 once the limiter lines are scanned. Although there isn't time to test it currently, the situation is intriguing. This uncertainty arises from the fact that ST programming is not familiar territory, leading to a gut feeling that something is amiss. However, it's important to note that while the calculation result may be seen before the limiter, the rest of the program will not use this value as the limiter will adjust it before it's applied elsewhere. The HMI may capture the 2.208 reading at that moment, but it won't impact the overall functionality of the program.
Thank you for the information. I made the necessary adjustments to fix the issue on the Human Machine Interface (HMI), and now it seems to be resolved. The values have been updated as follows: NHWL_K1 is set to 10.197, NHWL_C1 to -0.84, NHWL_Q to GX_80GOV, NHWL_P1 to (GX_JB17_63SPIRAL_CASE / 100), NHWL_P2 to (GX_JB17_63DRAFT_TUBE / 100), and NHWL_Energy_Kinematic_Global to (NHWL_Q squared divided by 274).
The formula for NHWL_Hn has been calculated as ((NHWL_P1 - NHWL_P2) multiplied by NHWL_K1) plus NHWL_C1 plus NHWL_Energy_Kinematic_Global. There is a conditional statement in place: if NHWL_Hn is greater than or equal to 68.0, then GX_NHWL is set to 68.0. If NHWL_Hn is less than or equal to 25.0, then GX_NHWL is set to 25.0. Otherwise, GX_NHWL is assigned the value of NHWL_Hn.
Do you need assistance with the syntax? It may appear unfamiliar at first glance, but it is correct.
Dalporto mentioned that the recent adjustments have successfully corrected the blip on the HMI display. The syntax of the code seems unusual but is technically correct. This issue is common in programming, as even experienced programmers find it quirky. This modification should effectively eliminate the blip in most scenarios. To further ensure the uninterrupted assignment process, you can utilize CPS(NHWL_Hn, GX_NHWL, 1); to prevent asynchronous HMI communication interruptions. Additionally, consider optimizing the code by writing to the final memory location only once using the updated conditional statement provided. This approach will enhance the stability and efficiency of the code execution.
Drbitboy pointed out that there may be an extra "END_IF" in the code. Despite the somewhat unconventional appearance of ST syntax, it is functional (even coming from someone with a history of programming in Fortran). This adjustment should address the issue of HMI glitches in most scenarios. For added certainty, one can utilize the command CPS(NHWL_Hn, GX_NHWL, 1) to prevent interruptions during the assignment process. Another approach is to update the final memory location only once by incorporating a condition like this: IF NHWL_Hn is greater than or equal to 68.0, set NHWL_Hn to 68.0; if NHWL_Hn is less than or equal to 25.0, set NHWL_Hn to 25.0; otherwise, keep NHWL_Hn unchanged. Additional instructions include ending with CPS(NHWL_Hn, GX_NHWL, 1). This method has been confirmed to work effectively. Thank you for your assistance, but please note that the second "END IF" is indispensable.
Dalporto pointed out that the second END IF statement is required. It appears I mistakenly thought the middle case was an ELSEIF without a space, rather than ELSE IF with a space. This difference results in two nested IF-ELSE-END_IF blocks, with the second entire IF-ELSE-END_IF being within the ELSE clause of the first outer IF-ELSE-END_IF. The code sample in question is:
```
IF NHWL_Hn >= 68.0 THEN
NHWL_Hn := 68.0;
ELSEIF NHWL_Hn <= 25.0 THEN
NHWL_Hn := 25.0;
ELSE
NHWL_Hn := NHWL_Hn;
END_IF;
CPS(NHWL_Hn, GX_NHWL, 1);
```
With the correct spacing, the code is interpreted as:
```
IF NHWL_Hn >= 68.0 THEN
NHWL_Hn := 68.0;
ELSE
IF NHWL_Hn <= 25.0 THEN
NHWL_Hn := 25.0;
ELSE
NHWL_Hn := NHWL_Hn;
END_IF;
END_IF;
CPS(NHWL_Hn, GX_NHWL, 1);
```
Considering that the software ignores line breaks, the most clear and concise layout for this code may be:
```
(* Clamp Hn output between upper limit of 68 and lower limit of 25 *)
IF NHWL_Hn >= 68.0 THEN NHWL_Hn := 68.0;
ELSEIF NHWL_Hn >= 25.0 THEN NHWL_Hn := NHWL_Hn;
ELSE NHWL_Hn := 25.0;
END_IF;
CPS(NHWL_Hn, GX_NHWL, 1);
```
Two distinct functional outcomes were presented by you all. In my view, the approach taken by DrBit is preferable. It's worth noting that the original Hn value is not being clamped in the code, which could potentially lead to problems if it is utilized elsewhere. If the Hn value is only being used within this particular routine and for the HMI display, then it might be acceptable. However, it does seem unusual to incorporate clamps solely for HMI purposes.
Encountering an error on Line 26: 'NHWL_Hn': Unexpected. It seems that the issue lies with the ELSEIF statement, as it may not be recognized as a command. Initially, I thought it was due to a Greater Than instead of a Lesser Than comparison, but upon further inspection, it appears to be related to the syntax of the ELSEIF statement. This error occurred on a L71 PLC.
Robertmee provided two distinct functional outcomes, with DrBit being the preferred method. It is important to note that the original Hn value should be clamped to avoid any potential issues if it is used elsewhere in the code. While it may be acceptable for it to be used solely in this routine and for HMI visualization, it may seem unusual to add clamps solely for HMI purposes. I have retained the original Hn variable but will be utilizing NHWL for logic and HMI feedback.
Dalporto mentioned that there seems to be an issue with the "ELSEIF" command not being recognized. This can be easily confused with "ELSIF," which is the correct command. When searching for clarification, I found this page to be the top result. Apologies for the oversight. In Logix, the correct keyword is ELSIF.
A new edition has been released by someone, available on page 134 of a document uploaded on a popular forum.
In the realm of engineering and automation, the concept of dampening plays a crucial role. Dampening calculations often involve setting a value between -1 and 1 to smooth out fluctuations in analog data. This process helps reduce the erratic behavior of values, making systems more stable and reliable.
Within RSLogix500, a dampening instruction can be implemented using a formula that includes a constant value and the difference between the previous and new values. By adjusting the constant, engineers can fine-tune the level of dampening applied to the data, with a lower number providing greater dampening effect.
In the ladder logic programming, a compute instruction is used to apply the dampening formula to specific data points. By calculating the filtered value based on the constant and the difference between the new and previous values, engineers can effectively implement a dampening strategy to improve system performance.