Bug Tracking

I found a thread on version control but I was more interested in what you all do for bug tracking. My system is getting a little harry.

Build a "TRAP".

First you need to know the Bug-condition you are looking for.

Then you need to know how that particular section of the code works.

Then you need to build a "Trap" that watches for particular conditions that will or might cause the problem.

I usually use a SET to set a bit to indicate that one or more of the particular conditions I was watching for has occurred. That way I can tell in the morning if it occurred overnight.

(15)

Suppose you have eight conditions on a rung that controls the output. And say the output is getting turned off from time to time but the event is so random/infrequent/fast that you can't seem to catch it in the act.

So, like Terry said, you create eight latches, one for each contact on the rung and sit back and wait until it happens again. Then you take a look at the coils to find out which contact(s) is causing the problem.

Now go to that rung and refine your search by doing it all over again.


Option #2:

Stop writing hairy code


(69)

John

Hehe... I've been misunderstood.

Where I work we build several models using the same PLC. So each model has it's own software. Some elements are common while others are unique. We do a lot of custom stuff as well and of course that means yet another different software with slight modifications. So I can keep track of all the version all right.

The problem comes when I discover a bug on an existing program that can affect different models/software. I have to make sure I can go back and fix all the different ones and keep track of which ones are done and which need doing.

Does this make more sense? I now have so many different models that keeping track of things in to do lists is getting a little hairy.

Why not just put a sticker with the 'currently running' revision number on the CPU, EPROM, or wherever the program resides?

This sounds like too simple and answer, so I must not understand the question...

beerchug

-eric

I think what he means is that they have maybe 10 or more pieces of 'base' software and then they add bits on for different clients. So what he is asking is that if they discover a bugin the base software, how do they track if all the different final programs have had this bug fixed, if they need to etc.

I don't have an easy answer to your problem apart from a spreadsheet possibly.

If you list each clients component pieces of software on a spreadsheet and then when a bug comes along print a list of clients who have that part of software in their package. This way you can easily see which client needs which bugs fixed.

What initially it takes is a lot of disipline. If you have more than one employee making changes, do you end up with different versions scattered across different laptops. If you could, store the different programs on one central computer and make someone in charge of keeping it up todate and backed up.

For tracking changes (bugs aka revisions), I keep everything in a MDB database. I store software versions, contacts, operating system info, and a long note field. Another thing to do if it is a ladder program, use the first rung to store revision comments along with dates.

Another thing you could do is be god like and write perfect code everytime. I use to do this (some here still do) but I find that customer revisions (updates) help pay the bills.

Dificil they are the dependent of transition. Already it thought, a bug that occurs in the commutation of elements, where a variation milisegundes produces unlike condition the that expects.

Ok now we're on the right track (pun intended). Xion got it right.

Right now I use the To Do Lists in a program called Lotus Organizer. (Don't laugh, it was the only thing available at the time). Once a complete a fix I record it in a Word doc so I have a list of versions and fixes/upgrades. So you see I am pretty disciplined.

I could use a spreadsheet but that's just as hard to manage. The Access DB approach seems like the best idea. I think even better would be a web database approach. I've looked at things like Bugzilla but they're only geared towards one specific application.

BTW, I do keep track of the software version on a ladder rung and display it on the screen as well as putting a sticker on the back of the screen. That part works great.

As to the comments re making perfect code. You guys must be either making really really simple programs or you're all superhuman!

Don't know if it'll help but there's Version Control Software out there.

You could use the same Bill of Material or Engineering Release software that you use for keeping track of hardware. Simply assign a part number to the base software - Purple Painting Program Logic could be XXXX1 for example. Then if you have a custom project that uses this as the base program, include on your Bill of Material P/N XXXX1 Purple Painting Program Logic. Create a separate part number for the custom logic, XXXX9 Metal Flake Mixing Subroutine. Both show up on your Bill of Material, and when you do find a bug in the XXXX1 program, do a where used search and there you are. You can use your same Engineering Change Order system to keep track of program revisions, and which systems were upgrade, and so on.

Of course, that assumes you have some kind of Bill of Material data base software, and that these are machines for sale. If these are for in plant use and you don't have Bill of Material type info, you could use your accounting departments Fixed Asset tracking in a similar fashion.

By the way, for the bug tracking problem you didn't ask, my approach is similar to Terry's, but instead of using a latched flag bit, I use the flag bit to increment a counter. That way I can tell how often it occurs, I can go to another task while it tracks, and I can determine if it is recurring or a once only type problem.

Does "Modularization" ring a bell?

A well written, larger program should consist of essentially freestanding modules.

Modules can be created and saved as separate programs. They would not be expected to run although they might... however, they are just pieces of the puzzle.

The completed version of one particular program might contain modules "A-1", "B-1", "C-1",...

The completed version of a similar program might contain modules "A-1", "B-3", "C-2",...

"A-#", "B-#" and "C-#" represent modules controlling their respective components. "B-2" represents the second version of Module-B. By the way, you don't have to have a "B" module... you could just as easily have a system with "A-2", "C-3", "G-2",... that is, if the physical nature of the system will allow.

You build a program by pasting copies of the appropriate modules from your library of modules into your program. First you get your "A", then you get your "B",... etc.

"Flags" are used to connect the modules. These flags provide communication between the modules. There needs to be a Standard on what flags are needed, how they are used and by whom. To a large extent, this is determined by the "neighbor modules".

Then, as Tom indicated, you can develop an order from the list of modules and build to order. Of course, there is always a new module in the making for those special orders. Having made the new module for the special order, the new module simply becomes another module in the library.

It's an easy plan to describe... but, it is a hard plan to stick to without discipline.

But, when it comes to updating a program with a new module... piece of cake!
Block & Cut... remove the old module
Block & Copy... get a copy of the new module from the library
Paste... paste the new module in where the old module was.

Tidy up a few flags, update the module list for the particular machine and you are done.

If the new program looks like it's gonna be one of your mainstays, then give that particular list of modules a new part number. Now it's one of your "standard programs".

Maintain an updated list of customer systems containing the list of modules in each system.

You might then consider determining upgrade charges based on the difference between the existing system and the desired system. At least, knowing what the existing system is will give you a clue as to what it's gonna take to bring the system up to date.

There are a million ways to bring order into any system. However, there are only an infinite number of immutable forces that seem to prefer chaos over order.

BTW, regarding the Bug-Trap, I should have mentioned the counters. I have many of these installed for "bug-trapping"... mostly to keep the production-folk honest.

(225)

Timotheos said:

I've looked at things like Bugzilla but they're only geared towards one specific application.

Click to expand...

BitKeeper perhaps?.

http://www.bitkeeper.com/

As to the comments re making perfect code. You guys must be either making really really simple programs or you're all superhuman!

Click to expand...

Hey! Anybody got an example for "Hello World" for a Series Six?


John