In response to @robertmeewrote's query (+1e6), it's worth noting that in ladder logic, there is no "ELSE" statement. The closest analogy would be using one rung for "IF a" followed by a second rung for "IF NOT a". This setup can make things more intriguing, especially when the value of 'a' changes from True to False.
There is no ELSE statement in ladder logic, but the ELSE functionality is implicit. In a rung with a NO contact instruction labeled 'Input' controlling a coil instruction labeled 'Output', the logic translates to: If Input is true, then set Output to True; otherwise, set Output to False. When converting ladder logic to structured text, it is important not to overlook this implicit ELSE statement. In contrast, a rung with a NO contact instruction labeled 'Input' controlling a latch instruction labeled 'Output' eliminates the implicit ELSE and necessitates another rung to control an unlatch coil.
I have chosen not to buy the addon at this time. Instead, I have outlined my requirements for a staircase design. Unfortunately, elegance is not a top priority in my considerations.
- 17-08-2024
- thehoneybadger
thehoneybadger mentioned that they are holding off on buying the addon for now. They have instead opted to list out their requirements for the ladder, but they feel that the result is not very elegant. There is also a divide by 0 error that still needs to be resolved, specifically with the first tag P1S[188] resulting in an error. Check out the attached image for more details.
It is necessary to consider eliminating the value of 0 in this scenario. Despite being a manually inputted value, the 0 will often be entered in this application. Thus, it cannot be completely disregarded. The IF rung I developed acknowledges the possibility of 0 and provides instructions on how to handle it if a value is divided by 0. This particular branch ensures that if a very large positive or negative number is encountered, the result will be 0. While this approach may seem simplistic, it is expected to be effective in practice.
- 18-08-2024
- thehoneybadger
Avoiding unnecessary calculations is crucial. Rather than executing all calculation logic when entering 0 to close the valve, consider implementing conditional logic. If the value is less than or equal to 0, disable calculations and reset the timer to 0. This simple adjustment can improve efficiency and save time.
I fully concur with MikeyN. It is common knowledge that attempting to divide by zero will result in an exception response, causing delays in processing. Implementing a couple of rungs to prevent such a scenario will ultimately save resources compared to handling the aftermath. Additionally, it is crucial to consider future scenarios. Imagine ten years down the line, when someone else, or even yourself, may need to migrate your code to a different processor that may not be as lenient. Preparing for such eventualities now can prevent major headaches later on.
Steve Bailey pointed out that although the ELSE condition is implicit in some cases, it is not always the case. This is particularly true when the output involves MOVs, OTLs, or OTUs. In such situations, the implicit ELSE condition is not present.
Yes, this is true when the output is equivalent to one or more coils (OTE). This applies to TON instructions as well. If the enable condition is True, then the Accumulated Value is increased by the elapsed time since the last evaluation. Otherwise, the Accumulated Value is reset to 0. It's important to note that the implied Else is not present in retentive timer instructions or counters with embedded one-shots. It's crucial to acknowledge the implied Else and understand that it means to do nothing. It's safer to consider the implied Else rather than ignoring it. Apologies to the original poster for going off topic.
After a thoughtful consideration, thehoneybadger decided to hold off on purchasing the addon for now. Instead, they chose to focus on improving what they already have in their ladder. The idea of elegance is not the first thing that comes to mind. It is important to address any issues with the current setup first before considering any additional features. This approach essentially prioritizes the alternative option before anything else.
Steve Bailey also mentioned the importance of TON instructions, as well as counters, and various edge-detecting instructions like CTU, CTD, CTUD, FFL, FFU, BSL, BSR, MSG, FAL, and FSC.
Ken Moore mentioned that he is not certain about the specific Rockwell names, but the "basic" package includes ladder programming, while the Professional package offers support for all programming languages. For those with the basic package, structured text can be purchased as an additional feature. If you navigate to the help tab, you will typically find an "about" option – what does it contain? It is still possible to use if/then/else statements in ladder logic. Click to expand...Hello Ken, I believe you may be onto something...
- 18-08-2024
- thehoneybadger
In a forum discussion, user drbitboy suggested starting by fixing existing code before simplifying it further. With examples provided in attachments 70060, 70061, 70062, and 70063, the emphasis was on putting the ELSE statement first for better clarity. Exploring the use of LIM was also recommended for a neater code structure. Consider incorporating these suggestions to improve the efficiency and readability of your code.
- 18-08-2024
- thehoneybadger
drbitboy raised an interesting point about prioritizing the ELSE condition. The question revolves around the scenario where a certain rung is triggered every 4 seconds. If the value falls between specified limits and a certain action is taken, does it result in a temporary switch of a timer value before returning to its original setting? The concern here is whether this process has any negative effects. Find out more by viewing the attached image.
- 18-08-2024
- thehoneybadger
In order to optimize your code, start by addressing existing issues. Take a look at the attachments provided by drbitboy: attachment 70060 for a more streamlined approach, attachment 70061 for an even simpler version, and attachment 70062 for the most basic option. By prioritizing the ELSE statement first, you can enhance the efficiency of your code. Consider implementing the simplest option for optimal results.
- 18-08-2024
- thehoneybadger
The Honeybadger raised a query about prioritizing the ELSE condition before other instructions in a ladder logic program. This particular rung is triggered every 4 seconds and involves checking if the value of A_Calc... [188] falls within specified limits, like 12345, and temporarily moving B_tr_Water... P1S[18] to a timer.PRE. This setup raises the question of whether the timer.PRE briefly changes to 0 before reverting back to 12345 on each 4-second cycle. Is this sequence problematic?
The answer hinges on the program structure. If all the mentioned MOV instructions are part of the same task, such as the continuous task, then there is no issue. The transfer of values between B_tr_Watering_Time_P1s[1] and timer.PRE occurs on a different rung and does not interfere with the evaluation order within the current rung. The execution order within a single program/task is predictable.
However, if the rungs are not within the same task, then the order and timing between tasks on different schedules become uncertain. In cases where an STI task coexists with a continuous task, interruptions from the higher-priority STI task can impact the sequence. Nonetheless, if the code is structured in a way where the timer.PRE manipulation is confined to the continuous task, interruptions from other tasks should not result in the timer.PRE receiving an interim value of 0.
PLC programming emphasizes the importance of timing, highlighting when actions occur as more crucial than the actions themselves.
In PLC programming, the order of execution within a program/task is deterministic. However, if rungs are not part of the same task, the timing and order of instructions between multiple tasks on different schedules is non-deterministic. For instance, in an STI task, if the MOV instruction into the timer.PRE tag is in the continuous task and the STI task interrupts it, the STI task program will be evaluated before control returns to the continuous task. This ensures that intermediate values are not moved into the timer.PRE tag. Time is a crucial aspect of PLC programming, often more important than the task itself.
Regarding the execution of MOVE instructions on a rung, the instruction on the far left must be completed before the one on the right can begin execution. If the second MOVE instruction is dependent on a GEQ instruction which evaluates to FALSE, the first MOVE instruction will still be executed in Logix5000. The system recognizes when it has completed tasks on a rung and moves on to the next task sequentially. This ensures efficient and effective execution of instructions in PLC programming.
- 18-08-2024
- thehoneybadger
Aardwizz pointed out the presence of a Divide By Zero error in the code, resulting in a 1.$ value. It is crucial to ensure that all values in the V_AutoCal[ ] array are positive and non-zero to obtain a positive result. The programming language used, whether Excel, structured text, or ladder, is irrelevant. It is essential to always include non-zero protections before any division operation to avoid potential issues. While some environments may handle divide by zero errors without crashing, it is risky to rely on this universally. This example emphasizes the importance of handling user input errors. Although this pertains to a garden timer project, forming good coding habits is crucial. Others implementing similar logic in their own hobby projects using various platforms such as SBCs or embedded systems should be cautious, as not all systems handle divide by zero errors gracefully.
Utilize math flags to verify the outcome of a calculation, such as S:Z for a zero result or S:N for a negative result.
The Honeybadger mentioned the importance of value limits when using calculations in programming. It is crucial to ensure that the value falls within specified limits, such as 12345. Additionally, it is essential to understand that the LIM instruction functions as a combination of Greater Than or Equal To (GEQ) and Less Than or Equal To (LEQ). This means that if the test operand is equal to either limit, the instruction will result in a true evaluation.
It is advisable to practice thorough limit checking in programming to prevent errors. This includes checking not only the divisor of DIV instructions for inequality to zero but also verifying the tags or addresses used as indices in indirect addressing. Neglecting limit checks can lead to machine faults, as seen when an out-of-bounds value entered a register used as an indirect address. In such cases, it is recommended to utilize a SIZE instruction to double-check the array's size and perform a LIMit check on the index tag before using it in the programming process.
I always believed that attempting to divide by zero or setting a negative value for a timer preset would cause the processor to crash. However, it seems that is not the case.
While it was previously believed that dividing by zero or setting a negative value for a timer preset would cause the processor to fault, it turns out that only a negative value will trigger a fault. This realization led to the development of a solution discussed in this thread to rectify the issue of negative values.
- 18-08-2024
- thehoneybadger
In the discussion, the Honey Badger clarified the sequence of instructions in a ladder logic rung. It was mentioned that each instruction on the left side of the rung must be completed before the ones on the right side can execute. This means that in a rung with MOVE instructions, the last MOVE instruction will be the one actually moving a value to the timer.
However, a question arose about what happens if a GEQ instruction evaluates to FALSE before a MOVE instruction dependent on it. In this scenario, based on the interpretation provided, it was assumed that nothing would happen as the first MOVE instruction cannot execute until the rung is complete. Yet, experience with PLCs suggests that the first MOVE instruction would still be executed as Logix5000 recognizes when it has reached the end of a rung and proceeds with the next task.
While the previous statement holds true for most instructions, it is important to note that each instruction is evaluated in a specific order based on inputs from the rung and the previous scan cycle. For instance, a MOVE instruction will only overwrite a tag's value if its input rung is True, setting its output rung state accordingly. On the other hand, instructions like TON or TOF behave differently based on the input rung's state, resetting or continuing timing operations as necessary.
Therefore, while MOV instructions may follow the pattern described earlier, it is crucial to understand that the execution of each instruction in a ladder logic rung is influenced by various factors, ensuring the proper functioning of the PLC system.
In a post by drbitboy, it was mentioned that while most instructions follow a deterministic order of evaluation, it is important to note that this is not universally true. The execution of instructions is influenced by various factors, including the state of the input rung and the previous scan cycle. For example, when it comes to a MOV instruction, the outcome is determined by the state of the input rung. If the input rung is True, the MOV instruction will overwrite the value of the tag referenced by the Dest parameter with the value of the Source parameter and set its output rung state to True. On the other hand, if the input rung is False, the MOV instruction will not change the value of the Dest parameter and set its output rung state to False. While this applies to MOV instructions, other instructions like TON or TOF behave differently based on the input rung state. For instance, a FALSE input rung will reset a TON, while a FALSE input rung for a TOF will either continue timing or expire based on the previous scan cycle. Conversely, a TRUE input rung for a TOF will prepare it to start timing on the next scan cycle. This discussion sheds light on the intricacies of instruction execution in programmable logic controllers. Thank you, DrB.
- 18-08-2024
- thehoneybadger