Analyzing your work

I'm finishing up a new program, and as usual, I'm going over it to look for things I can change, improve, tighten up, etc. My objectives are, in order:

1. Robustness
2. Modularity
3. Simplicity

Now, when working with ladder, it's not a "big picture" sort of language, and that's what I'm trying to accomplish. To show the interrelationships of all the different states, and the sequences in each.

I've tried analyzing with flow charts, but this doesn't seem to work. Flow charts are more for the process, not the program, and while you can derive a program from a flow chart, going in reverse doesn't seem to work as well.

So, for you master gurus, what method do you use to check your work? Do you indeed use flow charts? Do you rewrite the program in BASIC? And how detailed do you get in the analysis?

Any examples would be really helpful.

Thanks!

TM

Hi Timothy,

you say "flow chart" but also "states", so maybe you are really using state diagrams (and not flow charts).

Myself, I use state diagrams if the problem is so complex that the program doesnt "write itself" in ladder.
It is great because it is the perfect tool to really get a working and robust program. However, the program that is written in ladder based on the state diagram isnt easy to follow (as you write yourself).

I am t.h.i.n.k.i.n.g about getting a shrink-wrapped state diagram package for STEP7 (HiGraph). This should make it possible to follow the state diagram while online. But it isnt exactly cheap (around 1000 euro).

About how I test:
I make a list of "abnormal cases" that the program must work with.
The normal situation is the easiest part.
The difficult part is to hypothetically imagine all the odd situations that can happen.
When the program passes the list of cases, then I consider it to be stable.

Timothy, when "checking" my work there are several approaches I take (using the plc simulator in Step 7):

To check functions that can be represented in a flow chart (i.e. non ladder logic), I formulate test data that ensures that
(a) each line of code has been executed at least once.
(b) Each compare statement is executed with data below, at, and above the comparisons set.
(c) Any computation data is verifed against previously calculated data.

Note that this may result in generating say 20 calls to a block with different test data. (If more calls are required then maybe the block is too big and needs to be split down)
For functional testing I write a simulation block for each actuator. For example a valve would turn on its limit switch so many seconds after the Q output turned on. (The simulation is called at the start of OB1 and at the start of the timed interrupt and writes to the PII). A linear axes would take speed demand and integrate it to produce an actual position value.

I have found this elimates a lot of errors before getting near any real hardware when progress then starts to slow down.

If I could I would use something similar to Simon's methods. Typically my schedule is a little more compressed. The machine is often waiting for me to complete the code. So I am often in the position of just dumping the software in the machine and using a systematic test plan to test all the functions. As Simon states, it is slower as you need to proceed with more caution. So if you can simulate by all means do it.

The three things Timothy stated in the original post (robustness, modularity, simplicity) are design concepts. Simplicity and modularity are hard things to develop detailed tests for. You can test robustness to a certain degree. But even with that, only time will really tell.

I guess my overall point is, trust your initial design. Review things at that point. Then write the code and either test by simulation or on the target machine. To a large degree, a detailed offline review by you will only catch typos, which you probably won't have many of. Since you wrote the code in the first place and presumably didn't intentionally insert any errors, everything is going to look right to you when you go through it anyway. If you want to have someone else look through it that may be a different story. But I would say don't spend alot of time with pure offline, non-simulation evaluations.

Keith

Thanks for the ideas guys. Even "Forget about it" is an idea!

My goal in this process isn't exaclty to improve this machine. That's done already. My goal is to improve MYSELF, to find another way of analyzing my logic that will help me find ways to make it more robust, simpler, and modular.

While researching this, I came across Peter Nachtwey's post on Mealy and Moore machines, and said to myself, "Ah-HA!" I began making a truth table for one of the stations.

Problem is I set aside 100 Memory Bits per station.

16 Station Status (Home Done, Cycle Done, Busy, etc)
16 Commands (Home, Cycle Run, manual commands)
32 Faults (never use the same fault twice)
16 Inputs
16 Outputs

And that's not counting timers. So the truth table got pretty unwieldy, pretty fast. I also write my logic so certain things happen on entry to, or exit from, certain states, and the table was not very good at representing such transitional activity.

Still, I'm going to keep at it. Because the process of trying to shoe-horn my logic into this format may uncover something I'd not thought of - hopefully regarding simplicity

That's the sort of thing I'm looking for.

Thanks!

TM

TimothyMoulder said:

Do you rewrite the program in BASIC?

Click to expand...

I'm not sure why you'd do that. Converting a program to another language introduces more error, and what do you do with the BASIC program? Just recently I converted a CLX FBD routine to a CLX Ladder routine. Same programming software, different results. Of course, I was looking to take advantage of the differences. But, I had some unexpected surprises during my test phase. Sometimes things are just so subtle...

Anyway, is your question how do I test, or how do I improve? You seem to be looking more at the improvement angle.

To test, I download a program and use the best tools (IO simulators, emulators, etc.) I can get my hands on to verify that the program responds as expected. I don't spend a lot of time charting or graphing, especially after the fact. Charts and graphs don't guard against typos and Mexican jumping bits.

To improve a program, I do what my gut tells me. I always have a feeling about where things might be done better. (Man... 20 rungs for THAT?). Sometimes, taking a step back is all I need. Other times I may have to resort to K-maps, charts, a quick browse through a help file to look for advanced functions, or worse yet: asking someone else.

AK

I finally have a good example of what I was asking for when I started this topic

Last week, I was tooling through the used book store when I found and bought a book on Pascal programming. The first three chapters were all about documenting your programs and declaring variables.

Now, I've never been too pleased with my own ladder comments, so I decided to try applying the rules and methodology they used to my own. After some experimentation, I got it down to a manageable form that works well with my ladders.

The difference was enormous. Even I was shocked. I got some jpgs in the attached file.

Thanks!

TM

yea that does look better

it looks like it would help some one else that is trying to fig out u're code

believe me thats what i have been trying to do. figing out what some on else was thinking when the did the program