themullet01 said:
Kolyur and OkiePC suggested using the latching OTL and OTU outputs for lactching the different states. Do many people use this method?
If you need the status of the machine or the product to be remembered through a power cycle, fault condition, mode change, etc. then you must not use the OTE instruction unless you intend to add extra unnecessary code to copy the state.
I only use latch statements for state engines, preceeded by instruction clearing the whole field of bits, one bit per state (makes electrician searching easier) so they're enforced as mutually exclusive.
This is safe for abstraction, real I/O, not so much. Never directly address real I/O in the core sequence control, by the way.
themullet01 said:
I remember reading in a plc programming book once that this method can be discouraged and that it is better not to use latches for the states? What do you think?
Again, use common sense, I have never written a program without some latches for product and machine state tracking.
themullet01 said:
I suppose I am just trying to gauge what is best practice and will result in a better written program in the end.
Using the 'pause' or 'work' bit to inhibit the outputs as well as a transition to the next state is probably the easist solution but potentially the problem of the timers being reset and not holding their value still exists. Would everyone agree that the best thing to do is to simply wait until the current state is completed before stopping the sequence. This would solve a lot of the problems regarding stopping timers mid sequence?
THanks again.
Use the retentive timer: RTO.
I usually have two RTO timers for a sequence, one for the time in the current step, one for the total cycle time. This way, you can measure and study the duration of each step/state, even log it to find bottlenecks later.
On the rising edge of a state change, store the .acc value of the Current Step RTO, then load the PREset for the new step, and RESet it.
Alternatively, with state engines that are 16 states or less, using a unique timer for each one is fine too, use RTO, and reset them at the rising edge of the 1st step of your sequence. When the maintenance tech watches the timer file, he will see them all go to zero, then each one count up as the sequence progresses, stopping and leaving the accumulator there for study.
For time limits at the device level, like coil dwell and contactor restart delays, well those go right in the output driver logic, not in the sequence.
These are my practices, and they are relatively general purpose approaches.