Updated program II
[Whoops, we crossed posts; I will read yours and fix this later;-]
Hi again,
Summary
A lot of this is guesswork because the process is still not well understood by me. But I still think the fundamental problem is caused by the use of timers, which timers can expire in the PLC while the process is shutdown, resulting in the PLC mis-modeling the process. That said,
Anway, I attach an updated version of my code; either this or something similar should be able to handle a process re-start without a PLC re-start or manually putting a part on the conveyor to restart the logic.
My guess is that:
- your existing code uses the expiration of a timer or series of timers to trigger the drop, which expiration assumes the part is in place to be dropped;
- if the PLC timer(s) has(have) started and and not expired when the process is shutdown, and then that PLC expiration occurs while the process is shutdown, then the action triggered by that expiration does nothing;
- so at this point the PLC has mis-modeled the process, in that the PLC "thinks" the part has dropped, because the PLC sent the trigger to drop the part;
- and the actual process has not dropped the part, because the process was shut off when PLC sent the trigger to drop;
- so the PLC is waiting to detect that dropped part via the laser, which detection will not happen because the part has not, and will not, drop,
]*]while the process is probably waiting for the PLC trigger the drop, because it missed the trigger while it was shutdown.
My code senses a process re-start and modifies the basic logic that should eventually restore, to within the PLC, a correct model for the process state; the basic idea is to detect a process restart as a backup proxy for the [Part present on conveyor] bit, which bit is (I think) the laser's digital output that is True/1 when the part is in the window.
I am still not sure about the drop triggers, and I have used a generic [Platform fully raised] bit as a proxy for the transition between raising and dropping the part. Maybe that bit could be the expiration of a timer that is started either in normal operation or as a result of a process restart. However, if I am right that it is the timers that are causing the problem, then a better approach might be to eliminate all timers, or at least eliminate all timers that could cause the PLC to mis-model the process when a shutdown occurs.
Details
I misunderstood how an [ONS] works: I thought the bit address assigned to it was the bit used to detect the rising edge; I now realize it is the incoming
RUNG's rising edge that is detected (I told you I was a newbie
); the bit address assigned to the [ONS] stores the internal state of the [ONS] between scans. We still need more information about the process, and the difference between raising the part and dropping the part.
The [ONS] instruction implements the following logic:
Code:
Bit with One-shot
rising internal One-shot
edge state output
----| |-----------+---|/|--------( )----+---
| |
| |
| One-shot |
| internal |
| state |
+--------------( )----+
----
Semper in doctrina
