When a Routine has an S:FS bit and is frequently called from the main routine, it raises the question of when this bit is active. Will it only be active during the initial scan of the main routine or every time the sub routine is called? If the sub routine is continuously called without any preceding logic in the main routine, does the sub routine run repeatedly or just once with subsequent continual scanning? This raises concerns about the functionality and efficiency of the program.
The Logix system's S:FS system BOOL tag will only be true during the first scan after a CPU power cycle or a switch from Program Mode to Run/Remote Run Mode. It will remain true for only one scan, regardless of how many times it is triggered within the user program - specifically, the very first scan.
Every task has an S:FS instance associated with it. For a continuous task, this instance will be true immediately after powering up. In the case of a periodic task, the S:FS instance will become true upon the first execution after powering up, which may take some time for longer intervals. As for event tasks, the S:FS instance will only become true when the task is executed for the first time, potentially days or weeks after the power up event occurs. The timing of when the S:FS instance becomes true depends on the specific event that triggers the task.
If the S:FS is located within a subroutine that is invoked from a JSR in the main routine during the initial scan, the subroutine will be executed once during startup. I am seeking clarity on the concept of synchronous and asynchronous operations. Specifically, I am unsure if the PLC records the JSR during the first scan and then executes the subroutine during the subsequent scan. Can you please provide more insight on this process?
fifty60 mentioned that if the S:FS is located within a subroutine and the subroutine is called from a JSR in the main routine during the first scan, then the subroutine will be executed once during startup. Each program in a PLC has its own unique S:FS bit, as opposed to a TASK as previously suggested. This S:FS bit is set for the first scan of each program. Typically, programs within a task follow a program schedule set in the task properties, causing all S:FS bits to be synchronized. However, it is possible to enable or disable programs manually or through program control. When calling a subroutine with an S:FS bit from the Main Routine, S:FS bits within the subroutine are not necessary as it will only be executed once when the processor enters RUN mode. If there is a delay (such as initialization timers) before calling the subroutine, the S:FS bit may no longer be active causing the JSR to fail. Regarding the confusion on synchronous and non-synchronous operations, the terms generally refer to the method of I/O update. In older A-B controllers, I/O updating occurred synchronously at the start and end of the logic scan. However, in Logix5000 systems, I/O is updated on a scheduled basis during the logic scan within the "System Overhead Time-Slice," which is an asynchronous process. In some cases, asynchronous I/O can pose issues, leading many to utilize mapping routines to re-synchronize data for the logic scan.
Reviving this discussion to inquire about the functionality of Safety: Fault Status (S:FS) in a system with Dual Redundant ControLogix. Does S:FS reset when a failover occurs? Given the synchronized scan cycle and tags of A & B chassis, it can be assumed that S:FS is also synchronized and will only trigger when both chassis are offline, and one is powered on as the primary controller.
In my experience, the S:FS bit gets activated every time the routine is initiated, not just during the initial scan of the main routine. Thus, if a sub routine is repetitively called without any preceding logic in the main routine, the bit will be set each time, leading the sub routine to run repeatedly. This could potentially cause efficiency issues if not managed effectively. It might be beneficial to evaluate if your program design can be optimized to reduce unnecessary calls to the sub routine.
The S:FS bit will only be active during the initial scan of the main routine, regardless of how frequently the sub-routine is called. For a sub-routine to run repeatedly, there needs to be some type of logic in the main routine to keep calling it. Without this, the sub-routine will run just once and then the continual scanning will occur. Making sure your logic flow in the main routine is optimally set up should ensure both functionality and efficiency of the program.
I think the S:FS bit should be active only during the initial scan of the main routine. The program should ideally turn this bit on at the start of its first scan and then immediately turn it off, not repeating this action every time the subroutine is called from the main routine. If no preceding logic calls the sub routine in the main routine, invoking it repeatedly without proper controls might risk creating an infinite loop, decreasing the efficiency of the program. It's crucial to have a well-structured flow to ensure the program’s functionality and prevent any potential hang-ups.
The S:FS bit is only set during the first scan after you enter RUN mode. It doesn't reset every time a subroutine is called. Now, if a subroutine doesn't have any preceding logic in the main routine, it will continuously run with every scan, regardless of the S:FS. This might seem inefficient, but it's sometimes necessary to continuously scan certain parts of a program to enhance response time or maintain system stability. The key lies in focusing on well-structured logic and ensuring your hardware can handle your programming's demands.
Great question! The S:FS bit, which stands for "First Scan," is indeed tricky when dealing with subroutines. It only activates during the initial pass of the main routine, so any subsequent calls to that subroutine won't trigger the FS condition again. If the main routine keeps calling the subroutine without any additional logic, the subroutine will run as often as it's called rather than just once. This behavior can lead to efficiency issues if not carefully managed, especially if the subroutine contains extensive logic or resource-intensive operations. In those cases, it might be worth considering how to structure your program to avoid unnecessary calls, perhaps by using flags to check if the subroutine has already executed some initialization logic.
Great question! The S:FS bit in a routine is typically set to true during the first scan of the main routine after the subroutine is called and remains active only until the next complete pass or scan cycle. So, if the subroutine is called repeatedly without any interruption in the main routine, it will still run multiple times, not just once. This may lead to performance issues if the subroutine is resource-intensive and doesn’t have a mechanism to prevent it from executing on every scan. It's crucial to optimize how and when those calls happen based on your program's logic to maintain efficiency and ensure you're not unnecessarily overwhelming the system.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: The S:FS bit is active every time the subroutine is called, not just during the initial scan of the main routine.
Answer: Answer: The subroutine will run repeatedly every time it is called, regardless of any preceding logic in the main routine.
Answer: Answer: The concerns mainly revolve around understanding when the S:FS bit is active, how it affects the execution of subroutines, and how it impacts the overall efficiency of the program.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.