Figuring out some Timer Instruction Issues - Micrologix 1200

[daba]

The SQO instruction might look complicated until you actually use it, understand what it does, and how it does it. Why build your own sequencer using methods that most consider bad practice when there's a perfectly good, tried and tested instruction provided to you.

Yet another benefit of using an "out-of-the-box" solution is that other programmers and maintenance people can also understand what it does, and how it does it, without trying to get into your head.

I'll wager that you will NOT be capable of writing any sequencing code that surpasses the SQO in terms of efficiency. To whet your appetite, your solenoid sequencing could most likely be done and dusted in about 10 minutes, using 1 line of code only. If the only thing stopping you using it is its "complexity", then I urge you to knuckle-down, and take the time to understand it. The same goes for any other instruction that "looks complex". They were put in the PLCs by clever people who deliberated long and hard what the instruction set should be.

 

[mike64b]

Sorry Mike, IMHO I don't believe your method is "easier to understand", on the basis that you didn't get it working, and made incorrect assumptions about data-table usage.

For a simple sequencing application like you described, the SQO was made for the job.

When I started in PLC control systems over 25 years ago, the guy who "mentored" me gave me lots of useful advice. He called them "rules" but they are not rules by any means....

Rule #15 : Let the processor scan all of the code in a file all of the time. At some point in time you will puzzling over a piece of code and wondering why it isn't working. If it's not being scanned, it won't work.

Rule #16 : Don't use JMP/LBL unless you HAVE TO. This ties in with rule #15.

Rule #17 : Don't use MCR zones unless you HAVE TO. This ties in with rule #15.

Rule #18 : Don't make your code "position dependant". This ties in with rule #15.

etc.

Daba, First can I say that your statement about it not being easy to understand because I didn't get something to work isn't really valid. The only reason it didn't work was because I a) forgot to clear a bit, and b) forgot to think of timer as data files. I would test it right now to see that it works but I don't have any equipment with me atm. (additionally, I didn't even get a chance to troubleshoot the code much because I had to leave early, so I figured I'd post on here to see what you guys thought until I could get back to it tomorrow).

Secondly, Unfortunately for me I began writing this project long before learning these rules and it has grown much too large to rewrite the code in the time I have remaining. I understand your concerns but my program does work and in my case, the time taken by RET's is not significant enough to cause issues for my application. I don't know what else to say....

 

[Lancie1]

I would test it right now to see that it works but I don't have any equipment with me atm.

I have the LogixPro Simulator that is good for testing. I could test it for you right now, and post a picture of the result - if I knew what it is supposed to do!

Secondly, Unfortunately for me I began writing this project long before learning these rules and it has grown much too large to rewrite the code in the time I have remaining.

You are going to learn, very soon, that time will be made available to you to rewrite poorly designed program logic. In most cases, the re-write always happens at the worst possible moment, with everyone standing around waiting while you fix non-standard and poorly-functioning routines that should have worked out-of-the-box.

 

[daba]

.... so I figured I'd post on here to see what you guys thought until I could get back to it tomorrow)....

Well, at least you now know what we think....

If you can't change the code on this project, (and just remember you WILL need to replace all ocurrancies of duplicated timers), then please more than consider doing it differently on the next.

good luck...

 

[Lancie1]

The PLC was in RUN mode, as shown by added Rung 002. The first two rungs never get enabled, unless B3:4/11 is turned on manually or forced on. I think there are better ways.

 

[Lancie1]

Mike, could this possibly be the logic that you were trying to write?

This program turns on Solenoid 2, waits 3 seconds, turns Solenoid 2 off, then turns on Solenoid 1 for 3 seconds, then repeats the cycle. The picture was made after Output O:2/1 had gone off, and Output O:2/0 has been on for 2.1 seconds.

 

[mike64b]

Well, at least you now know what we think....

If you can't change the code on this project, (and just remember you WILL need to replace all ocurrancies of duplicated timers), then please more than consider doing it differently on the next.

good luck...

In the future I agree, I'll need to do it the typical way..as for the timers, these are the only ones in my program so it's not a big issue.

As for Lancie1, thanks for the simulations, I should note that the B3:4/11 is turned on by the program but I didn't show that rung, the operation is similar to your second simulation where you use a "Program Start" relay to turn on B3:4/11. Anyways, I see it is pretty simple to do it using just conditional statements, so I think I'll do that.. Thanks

 

[Kev77]

Wow this can get you head spinning!

Lancie1 - On the first image that you posted (using Mikes Logic) you are using 2 timers. Mike is referenceing only one. So I decided to try it both ways and see what happens.

Mike,

First off, the ONLY way that rung 2 will be scanned is when B3:4/11 is off. B3:4/11 will NEVER unlatch (unless done manually) because rung 2 is not scanned.

When you use the same timer the way you did, when its done on rung 1, its done on rung 2 even if you are not scanning it. So when you manually turn off B3:4/11, T4:0 is still done.

If you run it with a different timer as Lancie1 shows, it will show you more of what is really going on.

I would be concerned with any machine running this type of logic and hope that the estops are hard wired!

I work on an old TI PLC that drives me NUTS because of jumps.

Just wondering, what is your PLC scan time?

I attached the Logix file if anyone wants to play with it.

 

[mike64b]

Kev77,

If you notice I edited my first post saying I forgot to add the unlatch for B3:4/11. It should go right above the second RET in your code you provided. So that once the first time is DONE, the B3:4/11 is unlatched, so that next time it comes into the program it will go to B3:4/13..

 

[[email protected]]

Dear sir
it is my first post so i am not sure im in right place or not but i have a serious problem we have s7(400)-wincc system and there is some belt scale and motor i have to write program to prepare shift report to separate working time and amount of production in each shift i tried some method but i couldnt get good result can any one have any experience about shift report programming? i neeed help pleaseeeeeeeee

 

[Kev77]

Like this???

 

[mike64b]

rh_abas, you need to create a new post, go here http://www.plctalk.net/qanda/forumdisplay.php?f=2 and start a new thread by clicking the "start a new thread " green button in top left corner.

You probably want to better describe your question there too.

 

[mike64b]

Like this???

Yeah, but I see you removed the Output relay energize for the output relays, but maybe you just did that for simplicity.

 

[daba]

Kev77,

If you notice I edited my first post saying I forgot to add the unlatch for B3:4/11. It should go right above the second RET in your code you provided. So that once the first time is DONE, the B3:4/11 is unlatched, so that next time it comes into the program it will go to B3:4/13..

Mike, your interpretation of what is happening is technically incorrect.

It will not "go to B3:4/13". The processor doesn't jump to the next rung because the rung above it is false (meaning the RET instructions don't get executed), they do. The WHOLE of each rung is scanned, and the processor executes every instruction with the "Rung Logic Continuity" set to false.

In the case of the RET instructions, they execute, but do nothing.
In the case of Timers, they execute, and get Reset.
In the case of OTL and OTU, they execute, but do nothing.
In the case of OTE instructions, they execute, and will write a zero to the bit address.

So, in your sequencer code, towards the end of the sequence, the processor will have executed so much superfluous code on all the "false" rungs, that any scan time you saved at the beginning of the sequence, is swamped by the scan time you introduce by having so many instructions.

Don't forget branch start (BST), next branch (NXB), and branch end (BND) are also processor instructions that need memory and consume execution time.

If I had the time, I could write a 50-step sequence using your methods, and determine the additional scan time you are adding at the end of the sequence because of all the preceding code. I can guarantee that the "mean" scan time will NOT be the same as the scan time at step 25.

You must get to grips with how the processor handles the code, and forget the idea that you can put more code in to "improve" on processor scan times, in many cases you can't, and the methods you use to do it, if successful, will almost certainly make the code harder for anyone else to follow and understand.

Having said all that, you do make a valid point that code needn't be executed unless it is needed - for high-performance motion-control projects in Logix5000 this is an absolute "must do".

So, take a look at the pic, which shows an SQO example, using just 2 instructions, that will sequence some outputs. The timing is effected by putting the code into the STI (Selectable Timed Interrupt) file, configured in this case in file 3. This file will execute every 1000mS. Each time the rung is scanned, it moves the next word from the binary data-file, masked by the bit pattern in the Mask, to the destination address, in this case an output word. You set the bit pattern how you want. The whole sequence can be changed instantly by COPying other Binary files to the one that is used in the SQO. Obviousy, you will need some additional control bits if the sequence needs to be switched On and Off (Active/Inactive). This is not hard to do, but remember to RESet the SQO control file if the sequence is inactive.

You can put multiple SQO instructions in the STI to control multiple sequences, and you will also find that by nature of the fact they all progress forwards in the same scan, they will be "sychronised". Using Timers in logic will not guarantee sychronism.

Using the STI function file, I have the absolute optimum execution, i.e. NO code is ever executed that "does nothing", and when it does something, its timing is spot-on because the code is executed by timed interrupt. You cannot get better than that, and I hope you are learning valuable lessons

 

[Kev77]

Yeah, but I see you removed the Output relay energize for the output relays, but maybe you just did that for simplicity.

Well if you download the free simulator and dump the program in you will see that the code doesn't work the way you see it. Daba is correct on saying that you should understand how scans work and I would suggest you do this before writing any code. Your misconceptions should not be taken lightly and could cause equipment damage or really furt someone.

The output was removed because I reached the nested branch limit and was unable to compile the code to run on the simulator.