AMarks95 stated that all ONS bits are unique and shared their approach to comparing PLC time to a time setpoint. By using a 250ms timer instead of a oneshot at the global level, they are able to trigger local bits within each sub program. This updated logic aims to provide more clarity and effectiveness in their programming. However, there is still some ambiguity in the description provided. It seems like there are multiple ONS instructions, a global bit, and various uses of the toggled bit. Perhaps utilizing a straightforward XIC global_oneshot OTE local_oneshotrung would simplify the process. It would be helpful to see screenshots of both the logic writing the global bit and the logic using the global bit for further clarification and analysis.
Do all Java Specification Requests (JSRs) to the following subroutines execute unconditionally?
drbitboy questioned whether it is feasible that the "multiple other programs" are all referencing the same "very first program." The potential connection between these programs was considered, but no definitive conclusion was reached.
Drbitboy expressed confusion about the description provided. It seems that there may be multiple ONS instructions, a single global bit, and multiple instances of "using a bit toggled by the global ONS." The question arises as to why a oneshot is used to trigger a local bit in a program when a global bit is already available. If the global bit is not intended for direct use, a simple XIC global_oneshot OTE local_oneshotrung could suffice. It would be helpful to see screenshots of the logic for both writing the global bit and using it.
In the initial program, there is a routine named "Clock_Control" that performs the following actions:
1. Creation of PLC time as a DINT in HHMM format, e.g., 8:32 am represented as 832.
2. Comparison of PLC time to a reset setpoint also in HHMM format.
3. If PLC_Time == Time_Setpoint, then ONS triggers OTE(Global_New_Day_Bit).
The global new day bit was previously utilized in subsequent programs for resetting tasks at the start of each day. To address this issue, the process has been modified as follows:
1. PLC time is created in HHMM format.
2. PLC time is compared to the reset setpoint.
3. If PLC_Time == Time_Setpoint, then TON triggers Global_New_Day_TON.
4. XIC(Global_New_Day_TON.TT) leads to OTE(Global_New_Day_Bit).
5. Each program now includes an additional line at the beginning of the main routine:
XIC(Global_New_Day_Bit) triggers ONS, resulting in OTE(Local_New_Day_Bit), which is then utilized in the program's subroutines.
In response to robertmee's query about the JSRs to subsequent subroutines, the answer is affirmative – all JSRs are unconditional.
AMarks95 asked a question about the description: what is unclear about it? When PLC_Time is equal to Time_Setpoint, the TON(Global_New_Day_TON) function is activated. It appears that there is a discrepancy in how the time comparison is managed, as Time_Setpoint was previously set to 0. It is possible that the clock never reaches 0 and directly switches to 1. However, this does not clarify why the system functions correctly on another PLC of the same series, where Time_Setpoint is set to 1.
I conducted a manual test where I set the PLC's time to 23:58 and observed it reset to 0 before the timer started. This rules out the possibility of the issue being related to the clock not hitting 0. With the main task's scan times at approximately 0.5ms, the system should be functioning properly. I will leave this new code over the weekend and assess its performance on Monday.
AMarks95 mentioned that the first program includes a subroutine named "Clock_Control." This subroutine performs the following tasks: 1. Creating PLC time as a DINT in HHMM format (e.g., 8:32 am as 832). 2. Comparing PLC time to a reset setpoint also in the HHMM format. 3. When PLC_Time is equal to Time_Setpoint, it triggers ONS and sets the Global_New_Day_Bit to OTE. In relation to the original post, it was mentioned that during the same scan cycle when step 3 wrote a 1 to Global_New_Day_Bit, there was a transition to 0 in that same scan cycle.
drbitboy mentioned in the original post that there was confusion regarding the change in the value of Global_New_Day_Bit during a scan cycle. The query was whether the value went from 1 to 0 in the same cycle. I should have clarified that I was unsure of the exact situation, only that the rung with the condition XIC(Global_New_Day_Bit) was not being executed. It was puzzling as to why it wasn't working as expected, so I made an educated guess to troubleshoot.
Robertmee asked if all JSRs to subsequent subroutines are executed unconditionally. Based on the observed behavior, the most probable answer to this question is that one or more programs are executed conditionally during each scan cycle. If a program does not run when the global one-shot bit is 1 (e.g. during the first scan cycle when the time value changes from 831 to 832), it will not detect a value of 1 in subsequent scan cycles within the same minute (832).
Unfortunately, I have some unfavorable news to deliver: an ONS will only trigger once during a scan, until the condition triggering it turns false. While you can keep an ONS active indefinitely, it will still only activate once. Therefore, ensuring proper placement and utilization of this instruction is crucial for optimal performance.
According to padees, it's important to note that an ONS only triggers once during the current scan cycle and the start of the next one. This action remains in effect until the ONS is re-evaluated, which could occur after many subsequent scans.
In order to trigger a response, a transition from false to true is necessary. Place an Output Neuron Symbol (ONS) on a lower rung to activate a component on a higher rung during the scanning process. Test this method to determine its effectiveness.
In programming, it is crucial to remember that logic should trigger a Jump to Subroutine (JSR) only once, especially when dealing with One-Shot Outputs (ONS) that may persist across multiple scan cycles. This is important to ensure consistent and expected outcomes, especially in the context of periodic tasks. Avoiding the reuse of one shots across routines or tasks can help prevent unexpected results down the line.
Robertmee mentioned that he doesn't often use one shots that need to persist across different routines or tasks. This can lead to unpredictable outcomes, especially since many tasks are periodic. It is recommended to stick to periodic tasks, although many programs today operate as continuous tasks. With faster processor speeds and ample memory, programs are more forgiving than ever.
Chelton highlighted the importance of having periodic tasks, although nowadays most programs operate as continuous tasks due to advancements in processor speeds and memory capacity. While programs are now more forgiving, it's important to note that this doesn't excuse poor programming practices.
NOTE: While I have not closely followed this discussion thread, it seems that some participants are misunderstanding how the ONS instruction functions in RSLogix5000. I aim to clarify these misconceptions. Please note that the example presented here is based on testing with the Version 16 Emulator, as it is the only testing tool available to me at this time.
In the MainRoutine displayed in the screenshot below, the value stored in COUNT_MAIN_ROUTINE_SCANS is steadily increasing, indicating that Rung 1 is being executed as TRUE and triggering Routine_A with each scan of the MainRoutine. However, contrary to what many programmers might assume, the value stored in COUNT_ROUTINE_A_SCANS does not change as expected due to the behavior of the ADD instruction.
It is important to address some common misconceptions about the ONS instruction. The "GREEN ON THE SCREEN" highlight does not always indicate that the instruction is currently TRUE or active. Similarly, while the Value of the ToolTip for the ONS instruction may show 1, this does not necessarily equate to TRUE.
In summary, the ONS instruction in Rockwell products may not always function as anticipated. It is worth noting that ONS and OSR instructions in other Rockwell platforms have different behaviors compared to the ControlLogix/CompactLogix platform discussed here.
This post aims to align everyone's understanding of the topic at hand. While my intention is not to provide a solution to the Original Poster's issue, I hope that clarifying these concepts will facilitate further discussion. Feel free to share your actual programming code for more detailed assistance. Peace to all.
Ron Beaufort mentioned that while he hasn't been closely following the discussion thread, he has noticed some common misconceptions regarding the ONS instruction in RSLogix5000. He aims to clarify these misconceptions and provide insight. The example he shared is based on the Version 16 Emulator. The MainRoutine is functioning smoothly, with the value in COUNT_MAIN_ROUTINE_SCANS steadily increasing. Despite expectations, the value in COUNT_ROUTINE_A_SCANS does not change due to the behavior of the ADD instruction.
One common misconception highlighted is that the "GREEN ON THE SCREEN" highlight of the ONS instruction does not always indicate that it is true or active. Additionally, the value of 1 in the ONS instruction's tag does not always equate to true. It is important to understand that the ONS instruction in Rockwell products may not always operate as expected.
It is noted that the ONS instruction may differ in functionality between different Rockwell platforms, such as RSLogix500/SLC/MicroLogix. The post is intended to provide clarity and promote a better understanding of the topic, rather than directly solving any specific problem. Ultimately, sharing actual programming code would be beneficial in advancing the discussion. Peace to all.
drbitboy pointed out that based on the behavior observed, the likely explanation for @robertmee's issue is that one or more programs are only executed conditionally during a specific scan cycle. If a program did not run during the scan cycle when the global one-shot bit was set to 1 (for example, during the 832nd scan cycle after being 831 on the previous one), it will not detect the value of 1 in any future scan cycles within the same minute (832). It is worth noting that there are no conditional Jump to Subroutine (JSR) instructions involved in this scenario.
padees mentioned that an ONS only triggers once during a scan, remaining inactive until reset. While you can keep it active indefinitely, it will only trigger once. Therefore, correct placement and usage are crucial for this instruction to work effectively. Yes, I understand how the ONS functions. My intention was to use a single ONS globally in the initial program to reset various settings at the start of each day in all subsequent programs. However, it is not behaving as anticipated, leading to confusion and prompting this post for clarification.
AMarks95 mentioned that they are familiar with how the ONS works and intended to utilize a single ONS globally in the initial program to reset various elements at the start of each day in subsequent programs. However, it appears that the ONS is not functioning as expected, leading to confusion and the need for assistance. With millions of installations showing no unexpected ONS issues, it is likely a unique problem specific to the code being used.
It is important to consider how many tasks are being utilized. If there are multiple tasks, some may be periodic and run asynchronously to the continuous task. In such cases, a global ONS cannot be effectively used. If interested, providing a copy of the original code for testing purposes can help identify the issue. Feel free to send a private message for further communication via email.
Achieving "millions" of installs may seem like a lofty goal, but breaking it down, it equates to over half a million installs per minute throughout the year. While it may feel like a long process, when broken down to seconds, it becomes more manageable. Ultimately, only you know your true capacity.
AMarks95 pointed out a discrepancy between expectations and outcomes while working on a project. They discovered that the issue lies in the code itself, not the PLC or one-shot. The PLC program operates solely based on the instructions provided, disregarding any intentions or desires. In simpler terms, it is frustrating when the PLC follows instructions to the letter, even if it's not the desired outcome. By sharing your code, you may uncover where expectations differed from reality in its functioning.
There could be two other potential but improbable causes to consider: a bug in the compiler used to create the PLC program for downloading, or faulty or damaged memory (such as in a PLC located in space).
AMarks95 confirmed that there are no conditional JSRs. Are there any premature RET (return) instructions in the JSR-invoked routines?
drbitboy inquired about the presence of early RET (return) instructions in JSR-called routines. It is important to verify that the routine is not being invoked multiple times within the program, as this could explain the observed behavior. If the routine is called more than once, the unusual results would be logical.
It seems that there are some misconceptions about how the ONS instruction works in RSLogix5000 among individuals participating in discussions here. In order to clarify, I demonstrate duplicating ONS functionality using contacts and coils in the ladder logic program. This exercise is aimed at providing a better understanding for all, assuming familiarity with contacts and coils. Rest assured, this should not present any new challenges for the original poster. Wishing peace and clarity to all involved.
While it is noted that OP does not currently have any conditional JSRs in place, it appears likely that certain routines may not be executing the XIC(Global_New_Day_Bit) test instruction during the same scan when the Global_New_Day_Bit registers a value of 1. There could be other factors at play, such as the one-shot bit being modified during the scan or ineffective one-shot actions, but this scenario seems the most plausible.
Given this scenario, an example utilizing conditional JSRs on a MicroLogix 1100 is presented to replicate the same effect of a single global one-shot event triggering subsequent events in downstream JSR-called subroutines on later scan cycles. The images provided have been cropped for better viewing, while the full images can be found in the accompanying .ZIP file.
It is assumed that OP does not currently have conditional JSRs in place, and they are simply being used as a workaround to replicate the issues described by OP. All subroutines (LADs 10, 20, 30) follow a structure where Rung 0000 contains the logic activated by the global one-shot, and Rung 0001 holds the logic executed each time the routine is called.
Before the first subroutine is triggered in the main routine:
Shortly after the first subroutine is triggered:
Shortly after the second subroutine is triggered:
Shortly after the third subroutine is triggered:
It seems like you had a lot going on. I hope you enjoyed yourself!
drbitboy inquired if there are any premature return instructions within the routines called by JSR. The answer is negative.
Chelton suggested verifying if the routine is being called from multiple places within the program, as this could explain the observed behavior. It is important to ensure that each subroutine is only called once to prevent any unexpected outcomes.
If the initial program is a recurring task, it may be the cause of the issue you are experiencing. This recurring task is being triggered multiple times before the rest of the operations are completed.
I have developed a simplified version of the program that includes a feature to toggle between utilizing the global ONS directly and the local ONS.5069-L320ER v32.14. It is perplexing as I have two programs with the same ONS logic, but one is functioning correctly while the other is not. Both programs are on the 5069-L320ER v32.14 platform.
Interestingly, the program that is working successfully executed both the ONS and TON implementations after some adjustments. On the other hand, the program that is not functioning correctly failed to work with either implementation. I have meticulously checked that all subroutines are being called only once, JSRs are unconditional and not AFI'd, each ONS bit is distinct, and each bit has only one destructive reference.
Program Status:
Working:
Not Working:
Have you ever made changes to a rung, saved the project with the rung still being edited, removed that rung while offline, and then re-downloaded the program to the controller? Find out more about this process here: https://rockwellautomation.custhelp.com/ci/okcsFattach/get/1139086_11
Is the ONS controller scope included in both versions? I remember you mentioned it earlier, but I just want to confirm. Furthermore, on the controller's advanced tab, what is the time slice currently set to, and which radio button is currently selected?
Did you make changes to a rung, save the project with the rung still being edited, delete that rung offline, and then re-download it to the controller? It's possible that could have caused the issue. We'll need to re-download it soon to see if that resolves the issue. Click here to expand and learn more.
Robertmee inquired about whether the ONS controller scope is present in both versions. Earlier confirmation was provided that it is indeed controller scoped. Additionally, clarification was sought on the time slice setting and the selected radio button on the controller's advanced tab. The advanced tab displays options for fault routine selection, power-up routine selection, and settings to align the project with the controller, enable consumed tags to use RPM, and report overflow faults.
User AMarks95 shared a simplified version of the program, with the main idea being... The "New_Day_ONS" serves as the memory bit for the ONS and is not the actual ONS result, typically not utilized in a contact (XIC). It resets the previous day's totals and totalizer at each New Day Minute. The issue lies not in why it is not functioning in one PLC, but rather why it is functioning in the other PLC.
I am intrigued by the decision of the original poster to create a new OSR system. As noted by the expert, utilizing the address of an ONS as an XIC is not typically done as it essentially turns it into an OTE. This results in losing the unique 'one-shot' feature that was the initial reason for its use.
User AMarks95 mentioned that it is possible to re-download the file in question to see if it resolves the issue. After re-investigating, changing the reset time to a non-zero value confirmed that the ONS rung executes and the totals are reset. It appears that there is a discrepancy as it works when the reset time is not set to 0, but not on the other file.
In PLC programming, "New_Day_ONS" serves as the memory bit for the ONS instruction. It does not hold the ONS result directly and is typically not used in a contact (XIC). When activated, it resets the previous day's totals and the totalizer every New Day Minute. The issue at hand is not why it is not functioning in one PLC, but rather why it is operational in the other PLC. These are two separate programs, with the first screenshot displaying a simplified version. In the second screenshot, "New_Day_ONS" is analogous to "Global_New_Day_ONS" in the first screenshot.
After further investigation, AMarks95 discovered that by adjusting the reset time to a non-zero value, the ONS rung successfully executes and the totals are reset. It seems that the functionality is impeded when the reset time is set to 0, but works fine on a different setting. It is worth noting that New_Day_ONS is distinct from NewDay_ONS.
plvlce questioned the reason behind the OP's decision to overhaul the OSR. According to the expert, while an ONS address can be utilized as an XIC, it is typically avoided as it essentially transforms it into an OTE. This results in the loss of the original 'one-shot' characteristic that was the initial reason for its usage. It is important to note that ONS bits hold exclusivity and are solely employed in the ONS instruction, without any other instruction or location.
AMarks95 pointed out that the actions being taken are different from what is being claimed. However, upon closer inspection of the images and the provided code, it is evident that the actual process being carried out aligns with the assertion.
Drbitboy noted the distinction between New_Day_ONS and NewDay_ONS, emphasizing that they are two separate programs. Based on the provided pictures and code, it is clear that they serve different purposes. This difference is significant as they cater to different functionalities, making them entirely distinct from one another. For further information, please click on the following link: https://imgur.com/3mLydMU.
When it comes to the RAS program, there is a distinction between NewDay_ONS and New_Day_ONS. While NewDay_ONS is recognized globally, New_Day_ONS is specific to each individual subprogram. Click to expand for more information on this differentiation.
To optimize the synchronization of actions across multiple programs based on clock minutes, consider setting a bit to OTE when you want the actions to occur. Use a local one-shot storage address in each program to trigger the necessary actions. The bit will automatically turn off a minute later, providing ample time to troubleshoot and allowing for a smooth transition the next day. This approach resembles DrBitboy's method, with the added benefit of eliminating the need for a timer.
Upon further investigation, it was discovered that adjusting the reset time to a non-zero value successfully triggers the ONS rung execution and resets the totals. It seems that the issue arises when the reset time is set to 0, despite it working on another occasion. Click here to see more details.
In a forum post, user drbitboy explained the concept of reset time in relation to the New_Day_Reset_Time_DINT tag in the Clock_Control routine, emphasizing that it is not to be confused with the PRE of the TON. See the attached image for further clarification.
OkiePC suggested using the OTE function to trigger actions in other programs based on the clock minute, with one-shot storage addresses in each program to control the actions. This method allows the bit to turn off a minute later, providing ample time for troubleshooting and smooth transitions the next day. While DrBitboy achieved a similar setup, I found it necessary to explore alternatives as the ONS direct to OTE wasn't functioning properly.
AMarks95 mentioned that while they didn't initially see the need for a timer, it was necessary when the ONS wasn't functioning properly with a straight connection to the OTE. The solution was to directly compare the timer to the controller's scope OTE bit, ensuring it remains true for a minute. By implementing an XIC with a unique storage bit in each relevant program, any issues related to call order or time-slicing affecting a global one-shot are eliminated. This approach ensures that each program has its own unique one-shot operation, independent of scope considerations.
AMarks95 mentioned that they did not see a need for the timer in their program. However, since the ONS did not work straight to the OTE, they had to come up with an alternative solution. If you are looking for a different approach, consider using the XIC condition for an OTL Reset_Bit logic. Incorporate this logic on the last rung of the final routine by setting up XIC Reset_Bit OTU Reset_Bit. It's frustrating to rely on timers to address race conditions within the program.
To analyze the detection of a one-shot, add "XIC(Global_New_Day_ONS)" and "ADD(someDINT,1,someDINT)" to each program routine. If discrepancies arise in results between two locations where the same program is running (possibly in different PLCs), investigate the variations causing these differences.
OkiePC suggested aligning the timer directly to the controller scope OTE bit for a reliable one-minute interval. By implementing an XIC operation with a unique storage bit in each relevant program, the risk of global one-shot malfunction due to call order or time-slicing issues is eliminated. This approach ensures that each program has its own exclusive one-shot operation, independent of scope constraints. I have adopted this method to prevent any potential race conditions within the controller, leading to a more robust system that does not necessitate additional timers. The functionality has been tested successfully by setting the PLC clock to 23:59 and observing the reset at the stroke of midnight.
To ensure proper programming in PLC-2, PLC-5, SLC-500, CompactLogix, and ControlLogix systems, it is crucial to use a unique tag for each ONS instruction only once within a program cycle. It is not recommended to reuse the same tag for other instructions like XIC and XIO. Similarly, an OTE tag should be assigned to an OTE instruction only once, while an OTL tag can be applied to multiple OTL instructions. Violating these guidelines may result in "EMO" (Error Machine Operation) in your PLC.
I am experiencing a perplexing issue with my code. It functions perfectly when I am actively monitoring it, but fails to run properly when left unattended. Despite adjusting the reset time setpoint and using SSV to adjust the system clock just before midnight, the PLC does not execute the programmed actions when left overnight in run mode. Interestingly, the same code operates flawlessly on a different PLC when I am not present to monitor it. This puzzling discrepancy highlights the challenges of ensuring consistent performance in automated systems.
Dealing with Schrodinger's code can be a challenge. Would you be able to provide the ACD files for both the functioning and faulty PLCs? Have you utilized the Logix compare tool to analyze them?
Do the ApplyDST and CSTOffset attributes in the GSV WALLCLOCKTIME entries match across both PLCs?
drbitboy inquired about the similarities between the ApplyDST and CSTOffset attributes of GSV WALLCLOCKTIME entries on both PLCs. Surprisingly, they are not the same; the ApplyDST attribute is enabled on the functioning PLC but not on the malfunctioning one. Both PLCs have their times synced daily at 4am from a Windows PC which adjusts for Daylight Saving Time. Unsure of the function of the ApplyDST option, drbitboy may update it, although it may not make a difference unless it coincides with the day the clocks change.
With a whopping 5-page read, this must be some seriously intelligent content worth diving into.
User L33er expressed dismay over the extensive length of the content, assuming it must contain significant intelligence. However, the reality is quite the opposite - the solution is straightforward, causing unnecessary confusion among readers.
AMarks95 mentioned that the feature is enabled on the working device but not on the malfunctioning one. Both devices have their times synced daily at 4am from a Windows PC to adjust for Daylight Saving Time. AMarks95 is unsure about the purpose of enabling this feature and will consider updating it. While having the same local time should theoretically not affect the code using LocalDateTime, discrepancies between the settings on the two devices could explain why identical code produces different outcomes. It is worth investigating further to determine the root cause of the issue.
In a recent forum post, drbitboy discussed a scenario where identical code gave different results on two PLCs, possibly due to discrepancies in local times. While using LocalDateTime for calculations should theoretically keep results consistent, variations in time settings between the two PLCs can lead to unexpected outcomes.
Upon further investigation, the root cause was identified outside of the PLC code. The issue was traced back to a distributed Ignition system comprising a central gateway and five edge gateways (referred to as areas 1-5). Each edge gateway runs the same program as the central gateway but is limited to a specific operation area and connected to that area's PLC.
The problem stemmed from a script running on the central gateway at 4am to synchronize PLC times based on computer time. Due to oversight, the script was not properly restricted to the central gateway, causing discrepancies in time settings. Additionally, a misconfigured PC time in Area 3 exacerbated the issue.
As a result of these factors, the PLC time in Area 3 was reset multiple times throughout the day, leading to inconsistencies in comparisons. To address this, the script execution for clock resets was refined to only occur from the central gateway, with necessary adjustments made to the PC time in Area 3.
AMarks95 revealed the root cause of the issue: it was not related to the PLC code as initially thought. This specific case involves a distributed Ignition system consisting of a central gateway and 5 edge gateways, designated as central and areas 1-5, respectively. Each edge gateway operates the same program as the central one but is only connected to its respective PLC in that area. A script on the central gateway is scheduled to run at 4 am daily to synchronize all PLC times with the computer time.
The problem arose when this script executed on both the central and area 3 gateways, resulting in the PLC time in area 3 being reset incorrectly. This mismatch in time caused discrepancies leading to a failed comparison process. To address this issue, the script execution has been restricted to the central gateway only, and the PC time in area 3 has been corrected.
It's worth noting that this issue led to undeserved criticism of ONS throughout the discussion threads. An apology to ONS for the misunderstanding is well-deserved.
AMarks95 stated that the issue was not with the PLC code. Welcome to the club of those who have experienced the frustration of the PLC not following instructions as expected. It seems that sometimes, even for experts, the PLC will do what you tell it to do, rather than what you want it to do. Join the club of those who have learned this lesson the hard way.