How many edits does it take?

I am affiliated with a Car Wash manufacturer. The automated equipment uses a plc. Is there a cut and dry way to program an automated machine without the program needing to be edited 100 times ? They have been trying to perfect a program for 2+ years now, why is this so hard????? Am I dealing with ameturers or is editing a program over and over common? A few edits I understand but 100+ seems insane. Any comments would be apreciated.

Sounds like you are dealing with amateurs. Even the most complicated of programs should be debugged long before two years and 100 edits...

Maybe they are trying to program themselves out of a mechanical problem (or several mechanical problems).

That, or the project wasnt defined well enough to begin with. If that is the case, then it easily happens that the program goes in a wrong direction. It is not usually possible to define the job 100% in advance, but 95% should be possible.
Is this their first car-wash project ?

I've run into a few "programmers" who were totally self taught in the art of programming. The whole idea of developing a flowchart to them is a totally unheard of concept.

Also, in many cases in large originizations theres not true intergrator on the project. The project seems to be broken down into tasks done on the project by different teams that dont fully understand the entire application. Hence you have the job of the intergrater. This guy is supposed to get everybody togeather and develop a flow chart of the sequence of operations. Once the flowchart is done and everybody agrees on it, than you get down to programming.

This all may seem too obivous, but I've seen it happen, resulting in a program, or system that never really works quite right, and requires constant trial and error editing.

Also consider the idea of trying to program around the misapplication of field devices. I've seen some posts here, where the programmer seems to be having a problem attempting to get the results he needs due to the use of the wrong components in the field.

steve708 said:

100 edits...

Click to expand...

Have you ever had one of those days?

To everything that's already been expressed you can add the phenomenon of 'mission creep'. It arises out of poor specifications, but it also happens when people see that the PLC is capable of doing things that they didn't realize were possible. It can also be in response to customers asking for additional features and the programmer trying to please everybody.

It certainly could be a symptom of a sloppy programmer. It could also be a symptom of poor project management.

From Steve...

It can also be in response to customers asking for additional features and the programmer trying to please everybody.

Click to expand...

I find I have to constantly fight the urge to do this. All of these 'little' changes tend to add up to quite a bit of extra time. And they seldom work right the first time since you skimp on the planning phase because you are 'right there'.
I suspect many of us have to fight this. The same psychological 'affliction' that enables the people on this site to hand out gratis advice will also influence there choice to add 'just one more feature while you're here'. It does come down to project management in this case. Even if the programmer and project manager are the same person, you need to be able to switch hats as needed.

Keith

There are millions of ways to skin a cat, that is if you like cat. The thought of trying to overcome a machines mechanical limitations with software reminds me of putting the cart before the horse, it's harder to steer it and sometimes it gets so far off the track it will never recover. This sounds like the problem your programmers are trying to overcome. I suggest if the process or machinery can handle some "slopp" or "dead zoning" then do it. Besides it may save some additional headaches when dealing with that one occasional out of spec input!

Bitmore

100 Edits to the original program during the integration (Debug) phase is not uncommon for me, this is mostly before shipment and a week or two on site. 2 years is. Once the initial setup & debug is done I wouln't expect more than a couple of fine tuning updates. Although as pointed out often during one of these an unforseen result happens or customer "While your here" requests leads to more problems. Sometimes a small while your here feature causes a problem that may not be imediately detected.

I aint far away

What brand/model PLC is it?

geez a carwash?

How hard should it be? Personally my programs normally have very few problems, but then again they are mostly stand alone PLC's with a few RIO's. I use state logic which cuts my debug time down to very little. There are going to be changes made of course because of mechanical issues most of the time. Typos are common for me also. When programming I emulate each section of the machine after I am done to test the operation. I have the hardest time with large communication networks, dealing with different protocols. Mostly controlnet, maybe because I have not done alot of projects with it. I feel really comfortable with dnet, ethernet, DH+, profibus. anyway thats my 2 cents.
Dallas

**sorry to sound ****y**

It would seem to me that you have a combination of several problems:

1) The programmers don't know what the system is supposed to do (poor specifications).

2) They probably don't know what the system can't do. (Progamming can't overcome the laws of physics - if a system is mechanically not sound you can't work around it with programming).

3) The progammers don't have a sufficient level of expertise to implement the proper program logic.

4)They don't have enough confidence or clout to point out to the owner that the system has reached the limits due to mechanical deficiencies or inadequate field devices.