Jump to content
John_R

sequence programming question

Recommended Posts

Hey All,

Looking for some insight towards sequence programming, I know some people say that it is the prefered method, although in my years of dealing with PLCs (mostly other peoples work) I rarely see it.

I have used sequences from time to time when I want to insure that a bit of code executes in an exact way. I'll use an MI as a sequence "Index", and when the Index equals X then I execute that net.

My question is whether the prefered method of advancing the Index is by incrementing or storing a number to the Index.

The times that I have done it I have put an Increment at the end of a given net so that when it completes the Index increments up a number, and then the next net starts with an Equal To that number, and so on until the end of the sequence where I end the net with a Reset to the Index MI to bring it back to the start.

I have a machine where the OEM has a sequencing program (Allen Bradley, but the same process), and I've noticed that they use a Store (Move) at the end each net (rung) to change the Index number, and at the end of the sequence they Store (Move) the Index number back to the start.

The only advantage to the Store method I see is that you can change the Index number by a larger amount (10, 20, 30, etc), and if you later want to insert another step you just give it a "in between" number (15, 25) and you dont have to go back through all the nets and change the Equal To number at the start of each net.

Anybody have opinions on this, which method is considered "best practice"?

Regards
JohnR
 

Share this post


Link to post
Share on other sites

Joe Tauser is the expert on this, but waaay back when I was programming computers with old fashioned languages that used line numbers, I would always number by tens for the precise reason you state - I would always later find the need to insert additional steps and re-numbering can be a pain. With PLCs, if the algorithm is relatively simple and properly planned out, there isn't as much need to insert steps, so I usually number by ones and use the increment function. If it were a very complex situation I would definitely number by tens and use the store direct or addition function to increase the step number by 10.

 

What I usually do is create a coil for each step number, such as: when MIx = 10, then coil MBx is ON, then precede each step with that coil as an activator (or gate). This allows multiple ladder rungs for each step in the state machine and a clear understanding of what is happening in the program. At the end of the series of steps, a condition must be satisfied to index the state machine.

Share this post


Link to post
Share on other sites

Yeah, Joe has been my mentor on many things over the past dozen years, he is my Unitronics (as well as other products) vendor.

He has seen snippets of my code work and always has advice to offer.

I just thought I'd throw this out to the community to see what kind of opinions I get.

Actually, I'm sitting at home for a while, just had a long over due hip replacement, so I'm off work for a couple months, I get tired of watching TV and I'm not much on playing solitare, so I find myself thinking about work related stuff, kind of sad isn't it?

But I'm able to remote into my PC at work and check things from here. A couple days ago one of the guys from work called me about problems with the afore mentioned A-B system, and looking at the sequencing method used there got me thing about different methods, which got me here seeking knowlege.....

JohnR

Share this post


Link to post
Share on other sites

I was discussing this with a colleague just last week.  I number my steps in 10's and use store functions.  As above, it allows additional steps to be inserted.  It also allows steps to be executed out of order.  As much as I like to think I know the project from the start, I have never used an incrementing index for this, since it is such a rigid framework.  

 

With Visilogic I use a subroutine per step and use a compare block to call the subroutine when that step is valid.  With U90 Ladder I use jumps to execute the current step and jump over the others.

 

Hope this helps.

Share this post


Link to post
Share on other sites

If I may pontificate - 

 

John's first post mentions that he rarely sees sequence programming in other programs.  That is so entirely true and a tragedy caused by a lack of proper training.  I can think of three customers who where taught to program by the PLC vendor's salesman, who never did a project himself and only had a basic knowledge of the PLC functions and how they go together.

 

If you look at the staff and operations of a typical machine builder, they spend a LOT of money on machining equipment and the mechanical designer, but often the electrician/panel builder is also the PLC programmer.

 

I have a standard saying about the machine builder's attitude - "Electricity is the evil thing needed to make my wonderful machine work".   I've arrived at this attitude by many different observations of actual machine makers.

 

The most important and almost always ignored Best Practice in programming is to plan and document your program before you start it.  A flow chart is my favorite tool, because you can document everything on it as you work through recreating it with PLC code.  I've attached one I did for a customer.

 

Further commentary would be most interesting!

 

Joe T.

Standard Machine Flowchart V1.3 11.16.14.pdf

  • Upvote 1

Share this post


Link to post
Share on other sites

Hey Joe,

I like the way you started out your post with a pompous 25 cent word....

One of my most recent projects was a retrofit to a machine that was originally built around Schneider products (PLC, HMI, VFD's), We've had this machine about a year, and it spent more time in the shop than on the production floor.

We have a high "moisture content" (food plant, gets washed top to bottom every night), I would bring this machine into the shop and dry it out, but every time it went back on the floor we would have issues with it.... and unfortunately I was not afforded the various pieces of Schnieder software needed to properly troubleshoot the issues (and the OEM lost interest in helping).

Anyway, the plant manager asked me what we could do to eliminate the problems, I convinced him to let me strip out the Schnieder stuff and replace it with A-B VFD's and Unitronics PLC (V570 up where the old HMI was and connected to an IO-D16A3-TO16 down in the control panel).

I did MODBUS control to the six A-B VFD's, and found that I needed to stagger the MODBUS calls else the commands would flounder, and some of the VFD's didn't get their command. I did a sequence routine, based on time, I put a two second pause between each sequence Increment for the startup or stopping of each VFD (which fit right into the OEM's suggested start/stop
 sequence).

I also lessened the MODBUS call burden by storing the previous command to an MI, and compare statements that if the command was not different from the last time, then skip that step.....

Lastly, each of the 12 MODBUS calls (6 for start/stop, 6 for speed) each went to it's own subroutine, which returns after the MODBUS FB "Function in Progress" bit clears, or if the FB returns a comms error so it doesn't hang over a lost comm......

so far, working well......

 

It would be interesting to hear how others use sequenced operations.......

JohnR

Share this post


Link to post
Share on other sites

Further commentary would be most interesting!

 

Any of us who consider ourselves real programmers are always looking for the most efficient, economical, and clever solution to a programming problem. But in reality, it's probably more important to write the code in such a way that it is clear and understandable to another person trying to read it. I like using a State Machine, when applicable, because it's very clear what is happening and it's very clear where in the algorithm you are when online with the PLC. Another side benefit is that it forces you to do what Joe Tauser suggests - organize and document your logic.

 

I do other things, such as group similar or related short pieces of code using SB1, as follows:

 

  SB1

--| |-- <one line of code>

        |

         <another, related line of code>

        |

         <yet another, related line of code>

 

This minimizes the number of ladder rungs and helps readability.

 

Another important thing to do that surprisingly many people don't is to name the Operands in such a way that it is VERY obvious what that operand does. A few extra keystrokes today can dramatically reduce the time spent trying to understand what you were doing two years ago when you wrote the code and now have forgotten.

 

I learned early on NOT to use the "Links & Jumps" tab to link operands on pushbuttons to jump to different displays. You will inevitably forget to enter one in the provided field. What I do is have a Subroutine called "HMI PBs" where I enter every display jump condition (I use a single MB for each display I will be wanting to jump to) and then everytime I have a jump PB in any HMI display, it will already be in the code and there is nothing to remember to make it work.

 

I have an HMI screen where I display the vlp filename and the Visilogic version number so that I know what file and version was used when the PLC program was last downloaded. It also includes important information like the PLC Name and the Ethernet address, when applicable, so that it is handy.

 

I always use Input and Output buffering, this can be important when the hardware unexpectedly has to be changed (change I/O module, or the technician mis-wired something). It also makes it easy to troubleshoot using an extra bit that can be controlled while online, or on a special screen, without having to "Force" I/O.

 

I turn OFF access to INFO mode (set SI50 to zero) to the customer, unless properly logged in (I use multiple login levels on every program I write). This helps prevent problems. When access to INFO mode is needed I use SB36 instead of changing SI50. I also provide a button for a soft reset (using SB300) so the customer doesn't have to power cycle in the event of a system change or problem that necessitates a restart.

 

This is off the top of my head - I'll add more stuff as I think of it.

  • Upvote 1

Share this post


Link to post
Share on other sites

Hi All..

I stumbled across this conversation by accident. I started my programming life with Machine Code and Assembly Language in the Mid 70's on Mini Computers and early Microprocessors. We were all teaching each other back then. The two pieces of "advice" that were regularly bandied about were

 

The last part is the coding, plan it , write it down, Flow Chart it, then don't top down code, implement your plan.

 

Write your code like its meant to be understood by someone in 20 years time, 'cause you just might be the someone.

 

I don't code a lot these days, mostly play with Networks and GPON but the rules still apply!

 

Nice to see a proper flow chart Joe.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...