Good day everyone, I just got into rs logix5000 programming. Can anyone help me explain how a sequence timer work? In my sample logic, i need multiple presets of the timer to turn on a latching switch and turns on the lamps 1,2,3 and 4 in every 5 sec. and when the 4th lamp is on, after 5 sec everything will reset.
logix5000 sequence timer (beginner)
- Thread starter rkrider
- Start date
Welcome to the forum!
You'll get plenty of help here if you're willing to get started and show your work so far, then explain where you're getting stuck. If you're hoping someone to straight out tell you the answer, you might have a harder time.
A tip to help you get started. Look at the timer's .ACC value, and read up on the comparator instructions LES, GRT and LIM. With that information, you should be able to make an attempt, and plenty of us will happily offer suggestions on what you come up with.
Good luck!
You'll get plenty of help here if you're willing to get started and show your work so far, then explain where you're getting stuck. If you're hoping someone to straight out tell you the answer, you might have a harder time.
A tip to help you get started. Look at the timer's .ACC value, and read up on the comparator instructions LES, GRT and LIM. With that information, you should be able to make an attempt, and plenty of us will happily offer suggestions on what you come up with.
Good luck!
Geoff White
Member
You say multiple timer presets and then you use 5 seconds for everything in your description of operation.
This is the KISS version
Load 1 into a dint when the sequence starts
when dint=1 run timer
when timer done turn latch required outputs and move 2 to dint
repeat for each step with different timers
when the last step is complete move 0 back to dint and reset outputs
This is the KISS version
Load 1 into a dint when the sequence starts
when dint=1 run timer
when timer done turn latch required outputs and move 2 to dint
repeat for each step with different timers
when the last step is complete move 0 back to dint and reset outputs
That's not KISS...that's overly complicated. Use one timer as a previous poster suggested and simple compare statements of the timers ACC value to turn on your outputs.
A fixed sequence like that cries out for the SQO instruction, it was built for just this sort of task.
And there's no need to use a Timer as a time-base either, it can be put into a periodic task and "advanced" automatically.
I often demonstrate a N/S : E/W intersection traffic light system using just 2 instructions in the whole PLC.
It has another benefit in that you don't need to edit the program to change the sequence (except if you are changing the length), you just change the data in the source file.
rkrider may already be familiar with it if he has used Logix5 or 500, he didn't say.... The instruction hasn't changed over the years, and is available in Logix5000.
It's great for an educational exercise, but in the "real world" this is also a poor suggestion.
I would make an argument: Use a single timer, which is reset after each step transition and the .PRE is updated for for each step.
You now have individual time setpoints for each step, AND you can make a useful HMI which indicates the current step number, current step time setpoint and current step accumulated time. Which, in the real world of sequence-based programming is most likely what you will see.:site:
^ agree if we're expanding the scope to create a sequencer...but the OP was after a simple solution for a school problem. Also agree don't use SQO in factory floor applications. Most techs hate them and can't troubleshoot them. A nicely layed out step sequencer in ladder is much easier for the maint tech to follow and troubleshoot and modify if needed.
janner_10
Lifetime Supporting Member
Not sure I agree with this line of thought. We program to get the machine working and as the customer has specified, not to what the tech wants or can / can't do.
As an OEM, it's commercially impractical to change tried and tested code because Fat Frank from maintenance doesn't like it.
John Morris
Lifetime Supporting Member
+1 to janner_10
That seems like a very short sighted approach. Maybe the difference between OEM for small machines and large scale SI systems. As a SI I make my code as easy to follow and troubleshoot while getting the job done. I don't want 2am phone calls because a sensor has failed and it takes an engineering degree to read the code to figure out what's going on. I don't subscribe to the thought that I can make the code as convoluted as I want as long as the machine does what it's asked TODAY. Because TOMORROW will come where something external fails or an added functionality is needed. I guess as an OEM that's your bread and butter. You want the customer to call you and spend more $ for a minor change. I dont...once I walk away from a system I want very little to do with minor add on in the future.
As a side note I have made a fair amount in the past 20 years rewriting OEM code for manufacturing for just that purpose....to conform to better standards and to make it easier for their techs to troubleshoot. Most OEM code is great...as I'm sure yours is...but some of it looks like a thousand monkeys at a typewriter
And lastly, don't discount the power of Frank (pretty condescending to call him fat) complaining to management about your code. Again I've gotten work from those complaints aND have been contracted back to the OEM to write future code for their plants.
Last edited:
I've done plenty of work as an SI, and I agree with janner_10 that you don't let low-end techs try an dictate how you program. Generally speaking, any OEM/SI should be providing good structured, tested, reliable code that adheres to the OEM/SI's documented standard (unless the customer specifically provides an adequate alternate)which provides adequate alarming/troubleshooting at the HMI/SCADA level.
However, often times in the sales phase of the project negotiations happen and things get cut. The corporate buyer pats themselves on the back for getting the OEM/SI to drop the price 10-20-30%, the result is less time to develop, test and commission which leads to shortcuts that may not be ideal for "bubba" the factory tech yet are sound programming practices. The OEM/SI gets beat up when change-orders become the norm because the customer thinks they are still getting the "Premium" package even though they have negotiated purchasing the "budget" package. The OEM/SI gets it done and hope they make a profit while getting the hell out of there ASAP. The end users at the factory end up paying the price.
Enough people complain that they didn't get what they really "wanted" (even though no URS was submitted and they signed off on process/functional descriptions and participated in FATs which the participants were more interested in free lunch and drinks after) so they bring in someone like yourself to "clean it up" and lose the $$$ they thought they were saving. Well, that corporate dude still looks like a rock star while plant gets grilled for spending money, and you walk off into the sunset looking like a hero.
Circle of life....
I wonder if we scared off the OP?
Last edited:
At what length of a fixed, pre-defined step sequence would it make sense to use the manufacturer-supplied, in-built, 100% tested, reliable, non-editable, single instruction, to achieve the goal ? 10 steps, 50 steps, 100 steps, 1000 steps ????
I am taken aback that much of this thread has been over whether we ought to adopt "home-brew" coding, that is going to cost us a lot of time in writing, debugging, and testing, purely so that Frank has a chance of understanding it.
I would suggest that Frank would be more at ease with the SQO instruction, he has nothing to debug on the procedural part, he only needs to look at the data it is working with.
What other instructions should we not use for fear of upsetting Frank ?
I am taken aback that much of this thread has been over whether we ought to adopt "home-brew" coding, that is going to cost us a lot of time in writing, debugging, and testing, purely so that Frank has a chance of understanding it.
I would suggest that Frank would be more at ease with the SQO instruction, he has nothing to debug on the procedural part, he only needs to look at the data it is working with.
What other instructions should we not use for fear of upsetting Frank ?
TOF's
Tell me that's a joke .....
Similar Topics
This should be a pretty easy question, would just like to have it explained a bit so I can understand it.
In the attached program, why does the...
Hi all,
I am setting up a PLC for data aggregation from multiple remote sites (35-50). Before I get too far into this here is the equipment and...
Anyone have some code I can use for refrigerant Compressors
Sequence Control
IE an example
Cascade Sequencers
The simplest sequencers use a...
Hi!
So my problem is a little funky, I had Studio 5000 v 24 and 30 installed, but forgot to install RSLogix (which I cannot go without). Is there...
So I had an odd request from a customer for the above. I have written the logic and tested it all in one PLC with only using 7 outputs and 7...
