Sign in to follow this  
Followers 0
gravitar

Interesting methodology of programming

10 posts in this topic

I had always wanted to get familiar with visual basic, so I started looking around the web to see if there's any good tutorials. I found a pretty good one, and as an aside, they talk about a particular programming philosophy called SDLC. You can read about it here: http://visualbasic.about.com/od/learnvbnet/a/LVBE_L2.htm It dawned on me that this would be at least somewhat applicable to PLC programming, too. So what I'm wondering is, do any of you use this technique? Everywhere I've been, the guiding principle has been to start writing code as quickly as possible, with little attention paid to planning beforehand. I don't think I've ever been in a situation where the design has taken longer than the programing and debugging stages.

Share this post


Link to post
Share on other sites
I have been taught something similar. I took a course called Software Engineering once that detailed some of this process. Do I use it? Not really. I do tend to plan out things before writing code, usually a flow chart of sorts in pencil. I just don't follow any formal steps since its just me writing the code and not a team.

Share this post


Link to post
Share on other sites
steps we use: 1. define the system (mechanical/electrical/PLC-and Motion control need) 2. define the Grafcet and the I/O + dicuss it afterwards and approve 3a. start programming 3b. if problems or issues come up during programming redefine Grafcet (go back to step 2) 4. start debugging 5. factory acceptance 6. Acceptance + changes at customer site. 7. write manual These steps are taken without really writting them down. It is just the way we work. Edited by beegee

Share this post


Link to post
Share on other sites
I wasn't familiar with Grafcet so I did a little reading.. Interesting. I suspect that you'd have to take a more disciplined systematic approach than we do with ladder logic!

Share this post


Link to post
Share on other sites
basically Grafcet is quite like SFC (which you probably know better)

Share this post


Link to post
Share on other sites
Hehehe... You obviously haven't been where I have. I was programming an automated warehouse system where the design document almost literally became the PLC program thanks to a few well chosen macros done in MS Excel. I'm definitely into life cycle programming. Make the initial program modular and then the changes during debug & maintenance are easier to implement & document. The one thing they didn't address in the article you referenced is End Of Life. I had to plan for that at one military installation. Just writing "throw out the PLC" didn't seem like a prudent sentence to include...

Share this post


Link to post
Share on other sites
I call it top down software design. Thats what I learned in college. And it has a very real application to ladder development. I break any program down into individual pieces and decide how the pieces will work toghether before I start coding. As a general rule of thumb, if a task can't be coded in less than twenty rungs, its not broken down well enough. Naturally, the less than twenty rungs rule is not hard and fast, but its a good place to start and it will keep you asking yourself "can I break this down more?"

Share this post


Link to post
Share on other sites
I've adapted my project life cycles into something very much like SDLC, a couple of previous jobs involved writing custom statistical analysis s/w for manufacturing, usually in VB, C/C++, or Delphi. To keep the actual coding down to a minimum, SDLC-like steps was perfect for coming to a meeting-of-the-minds with the customer. Then, as Alaric pointed out, top-down design/bottom-up implementation made coding more efficient.

Share this post


Link to post
Share on other sites
SDLC is the latest incarnation of the idea of "top down programming" or "constraints development" or a whole host of other terms. It is not a new concept, just a new name for an old concept. In the idea of SDLC, you design a program from the top down. You should be able to essentially "define" the program instead of actually writing it. Any problems in the program will then be either typographical problems or problems with the specification. The problem with SDLC is that by the time you finally get done with all the bureacracy, the business needs have already shifted and the whole thing turned into a waste of time. The alternative in the programming world is called "Extreme Programming" or "Agile Programming". This is a lot more akin to what most programmers are traditionally used to...banging out code and checking, checking, checking. XP and Agile tend to be much more "bottom up" oriented. You write a tool/library, and test, test, test. Then write another and another...and then start moving slowly "up" by combining lower level pieces of well tested code. If something isn't working right, start writing tests to try to duplicate the problem until you find the errant code section. There are two essentially "new" concepts in the agile world. First, there's a bigger emphasis on collaborative development vs. doing things solo, even down to the idea of having say 2 programmers sitting side-by-side working jointly on the same program. Second, and the one that I've become a fan of, is the concept of "use cases" or "unit tests". The idea here is that you write code to automatically run tests on the code to verify that it actually works. Any time that the program acts up, that generates another unit test. There should also be unit tests intentionally trying to break the program. A lot of the old ideas about creating "test beds" and such get rolled into the idea of unit testing. I haven't ever used it before and I thought a lot of the unit testing stuff was a huge waste of time. However, I have made two runs at it recently. One was a nightmare batching system that had essentially 4 different interacting processes going on that had to be synchronized only partly through the cycle. This was the first time I purposely put a full simulation system into the code and included unit testing and manually driven testing. It was enormously faster and resulted in far more solid code. Essentially so far any time that we had a failure in the real world that was actually a problem with the code, we have been able to successfully duplicate the situation in the simulation. I don't really see any practical way to do unit testing in PLC code without a simulation system. Plus once you get done with the program (and even then, it wouldn't be an easy thing to do), operator training and answering those "it must be the PLC!" accusations becomes trivial. Just turn on the simulator mode and run the PLC through it's paces. If you can't do it in the simulator, it can't be done. The second case is a very hairy bunch of queueing logic that is a product tracking system through the production line. It is written in VBA programming that is running inside of an HMI/SCADA. State is somewhat hard to visually observe in this system because of the size of the queue (hundreds of bins in the queue with merge and diverge points, so it's not even close to a straightforward queueing system). I started right out building the code bottom-up and I wrote a bunch of unit tests to beat the snot out of the code as I went. I can honestly say it did find a lot of subtle problems much faster.

Share this post


Link to post
Share on other sites
We had a 120 page definition before we started on our 3rd generation controller. The code is object oriented with well defined interfaces between the modules. Sometimes it is a pain in the but when you need information out of another object.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0