Using (hacking?) vendor devices and others....

Folks,

Am here to whinge and moan a little. Surely others have had similar experience and I would like to know how they handled the situation.

1) I have taken over PLC code that is written in Grafcet (little or no comments, no state names, states are all over the place. eg state 4 goes to state 11 goes to state 34 goes to state 2...).

2) The PLC communicates to multiple servo drives over a bus. The programmer found that rather than following the manufacturer's instructions to control the servos over the bus, it was simpler to use the bits to control the servo by the servo setup software. i.e. if you hover over the buttons of the servo setup software, it would show which bits were being used to control the servo. This is not shown in the servo programming manual. This makes it very hard for someone taking over the software (me) to establish what the servo is doing. I have spent over 3 weeks trying to get the servos to make simple movements using this method.

3) This earlier programmer has been in the company for quite a few years now and he gets everything to work. So in the eyes of the management, he is "God". If I have a problem getting it to work, the mantra is, "Ask Bob". (Names changed).

4) When I suggested constructively that we should write maintainable code, Bob's answer was, "Why reinvent the wheel? It works". I get the feeling he is trying to make himself indispensable. I put in comments and he just deleted the comments! (I am trying to not get personal now!).

Do share your experiences with me.

I have handled that same situation (numerous times) by:

1. Keeping backups of my own with comments...He can't delete my thumb drive unless he is a very good pick-pocket.

2. Publishing everything I learn to others. This gives you the reputation of being thorough, honest, and a good communicator. While not the same reputaion as God, it is still a good one to have.

3. Permanently fixing errors and bugs that I have always found in poorly constructed programs. Combined with item 2 (sharing of info), then you become better than God in the eyes of the operators and their bosses. Actually, then the prior god becomes mortal, but without finger pointing...just factual documentation of faults and fixes.

Superhero Syndrome is common in our field. A guy who thinks it's best to be cryptic and secretive only serves himself. But I believe, like a wise co-worker from my past always said, "A man raises himself most by lifting others..."

Paul

You need to do some politicking. Consensus building. Don't worry about Bob just yet. Share your problem with others. Try and get them to see your side and agree that you are right. Try this with his boss (who may be your boss too). Maybe go up another management level. Try to spread doubt and fear. Like "what if Bob leaves, dies or is terminated"? What happens on Bob's day off? What if Bob goes on vacation for a week and production breaks down down?

If that doesn't work, change the code to your liking, password it, and then make him beg for the passcode.

I once lost out on a huge plc job to a ‘bob/god’ because at that time I had never connected plc’s by ethernet.
They told me that bob/god could and so he would get the job. (They didn’t like the thought that they were going to pay me to learn - while bob/god already knew)

Well bob/god did the job and got it functioning in a fashion - while I read books on distributed control systems. (Well, a book - one afternoon lol)

After 6 months of bob/god not being able to make the system do exactly what they wanted and writing the most unintelligible code I have ever seen. ( I always suspected that even he got lost in his own spaghetti code) I inherited the job.

Since then bob/god now referred to, by all, as ‘ginger-bollocks’ doesn’t get to come anymore and I, although I shall never reach that exulted status, do all the work there - so hang on in there mate.

Going behind people like that after they leave is what I do for a living. Here is an experiance that I had while working for a large company. After being in the job for about 4 years, I did a machine with another "Bob/God". I was the main person for the actual programming and responsibility for the machine. However, BG did the selection and layout of the components in the control cabinet. He put a huge isolation transformer in the same cabinet as my embedded controller. I didn't want it there in the first place but he had the final say. However, after 3 weeks in conditioning the inside of the cabinet was getting so hot that the wire numbers were delaminating and my controller was starting to do funky stuff. I told my supervisor that we needed to get that out of there. He told me that BG designed it that way for a reason and it was staying. After fighting it for the final time, I waited for my supervisor to out of the office and instructed a tech to remove the transformer and place it neatly in the machine base. I figured at least the operator could warm his lunch on it. When the supervisor returned, he gave me a bunch a grief, but he soon got over it when the machine started to run better. It was the right thing to do and every bit of my engineering sense told me that. If you consider yourself a person of reasonable knowledge and experiance at your job and you can't figure it out after 3 weeks, it wasn't done right. Do what you think is the right thing, but you have to prove it. After I proved myself, then I gained a reputation not through politics but by actions. You are not going to beat BG at his own game. I am sure he knows how to play it well, so don't go there. However, like Paul said, cover yourself and document anything he tells you to do. Just get it in writing. Play dumb and say "Can you put that in an email? I want to make sure I understand your directions"
For your current problem, can you work it a little at a time and redo it? Do some testing on 1 drive at time and work it out the way you want to do it. Sounds like you could just change the program and then at the end of the day put the old code back in. This is usually how I refurb a machine. Prove your method and then 1 day switch it over to your program. Hope that helped and good luck with BG.

Folks!

Thanks a lot for all your advice.

Paul, I am glad you echoed some of my thoughts. I try hard to remain professional. I completely agree with you that we should be spreading the knowledge around.

Godfrey, I must admit I am still in the early stages in the company to start playing politics. However other control engineers in the company do give me knowing smiles when I tell them of the problems I am facing. This Bob who I work with is also very reluctant to change of any kind. (It is funny considering that he has an engineering degree and has 6 years of experience).

It was funny to read your story Goody. And motivating too. A few days ago, I was pretty much ready to hand in my papers. I thought I shouldn't make decisions when I am not in a cool state so I just let the anger pass.

ATU, I see a lot of resemblance between my life and what you told me. And you just reinforced what I thought too. I am slowly working on small bits of code and commenting as I go along. Touching the servo systems will be a while though. Yes, I consider myself quite competent but because of all the code thrown in, I have a hard time figuring it out. Put it this way: I commented a whole lot of code out and there was not change to the way the servo motors ran!

Thanks again, all of you. I do remember someone on here saying, "Nobody set out to write bad code intentionally". I tell myself that when I feel that I am hitting my head against a wall and not making progress.

"2. Publishing everything I learn to others. This gives you the reputation of being thorough, honest, and a good communicator. While not the same reputaion as God, it is still a good one to have."

That's a great policy. I want to make sure that the techs have access to all the same information that I have. Some people may want to be god by hording information, but I gladly let the techs get the glory when it comes to fixing something at 3 in the morning on a Saturday.

OkiePC said:

I have handled that same situation (numerous times) by:

1. Keeping backups of my own with comments...He can't delete my thumb drive unless he is a very good pick-pocket.

2. Publishing everything I learn to others. This gives you the reputation of being thorough, honest, and a good communicator. While not the same reputaion as God, it is still a good one to have.

3. Permanently fixing errors and bugs that I have always found in poorly constructed programs. Combined with item 2 (sharing of info), then you become better than God in the eyes of the operators and their bosses. Actually, then the prior god becomes mortal, but without finger pointing...just factual documentation of faults and fixes.

Superhero Syndrome is common in our field. A guy who thinks it's best to be cryptic and secretive only serves himself. But I believe, like a wise co-worker from my past always said, "A man raises himself most by lifting others..."

Paul

Click to expand...

I agree with Okie 100%,
My only addition to item 2 would be:
If I diagnose an error on my part, I also disclose the error to the invloved parties (internal team members, and or external customers), as well as the error correction that I have made. This demonstates a solid integrity policy, that leads to overall confidence in our solutions. If in the future, an annomally should arise, and we debug it not to have been an error on our part, it is accepted without question.

Plastic said:

I agree with Okie 100%,
My only addition to item 2 would be:
If I diagnose an error on my part, I also disclose the error to the invloved parties (internal team members, and or external customers), as well as the error correction that I have made. This demonstates a solid integrity policy, that leads to overall confidence in our solutions. If in the future, an annomally should arise, and we debug it not to have been an error on our part, it is accepted without question.

Click to expand...

Yes! It is always good to confess your mistakes. You pay a small price in ego, but gain a great benefit in credibility and approachability.

We (people who end up specializing in controls) tend to be regarded as being too smart to talk to. Some guys are intimidated and less likely to learn from us. But, when they see us make mistakes and actually confess to them, it makes everyone more comfortable communicating, and sets a good example. Pretty soon, you can get them to own up to mistakes that they'd have likely kept secret in the past.

Paul

I have always taken the approach of supplying as much information as possible including comments, training etc. This way the customer can take some ownership an perform some simple changes or deal with problems in the middle of the night. I then get the more interesting projects or the Bob re-writes because the customer now has a better understanding of how a machine should operate.