Programming Guidelines

Doug_Adam

Member
Join Date
Sep 2002
Location
Perth
Posts
948
G'day,

This is a followup post from my 'Programming Style' thread.
I have completed a draft guideline for programming PLCs for my company.
Due to interest expressed, I am posting a copy of it here, in MS word format.
Since it's a company document, I had to clear it with out IT section, and they made it a condition that I remove all references to the company.
I still need to polish it a bit, and fix up the appendices, but I don't anticipate changing it much.

I would like some feedback on it, if possible.
Mainly if you were a contractor bidding for a new machine or upgrade, what would your reaction to this document be?
Would it be helpful to you?
Could you use it against us?
How easy would it be to conform?
Would you want to do things a different way?
Would you rather lose business than follow the guideline?

One thing to note: our HMI is fixed (Citect - due to local product support and cause it's pretty good).
Also any other comments or pointing out glaring ommissions would be welcome.

Kind regards,

Doug
 
Doug,

I have just read through your guidelines, here are my thoughts to the questions you posed

1. My reaction to the document on first receiving it would be - If that is the way that they want it then I am happy to go along with it, if I feel that the document is too restrictive on me as a programmer then I would have to talk to XYZ company electrical engineer about it.

2. Helpful? well it tells me what you want from the program in terms of layout.

3. I am not totally sure that I could use it against you unless there was a problem with program being laid out as specified and then going pear shaped. but communications between XYZ company and myself should solve that problem

4. I would only want to do things a different way if I could prove that it would be more efficient to do so.

5. I think that I would rather follow the guidelines, sometimes it's nice to be told how the customer wants a program laid out etc rather than giving them the finished product only to be told 'we don't like it that way'

These are just a few personal thoughts, I expect that you will get many more, I feel that most of what you have written is what a good programmer would do any way, it is just a case of letting the programmer know how XYZ company do things, then maybe the maintenance guy at the sharp end will find it easier to fault find if all new machines or upgrades follow the same standard.


Paul
 
Excellent job, Doug! You are not asking for anything outrageous whatsoever. These are guidelines that should already be in use by any decent programmer, this just helps to reinforce it.

As an OEM, I would have no issues with your current requirements. They seem REAL easy to meet!... :D

The only item I see as "open-ended" is your Functional Specification... I understand your point, but who decides what is "plain enough" english for the non-technical guys?... :confused:

beerchug

-Eric
 
Hi Doug:

Thanks for sharing this with everyone.

Being a self-taught AB OEM guy I understood most of what you had there and will probably adopt some of it for my own use.

The one thing that was a little confusing to me was sec. 5.5.3 Run Enable. "Local and Manual run must reset when Local or Manual modes are de-selected" I'm not quite sure what this means.... :confused:

Great job and keep us posted.
 
Doug,

Realy good guidelines, I think you have covered most aspects of good doccumentation etc in great detail.
I would like to see an appendix attachment that would cover change control on any future modifications to either the programme or field wiring etc that may impact on process. This would be mandatory in most Companys that are audited by regulatory authorities such as the FDA etc.
I think you describe my concerns quite well in your Functional Specification paragraph, and an attachment where any changes could be recorded (date of change brief description change, signatures, software version,etc)would be, in my opinion, very useful.

Programmable access and program version control is becoming a big issue with regard to PLC controlled processes esp in the Pharmaceutical industry. Tracibility by proper doccumentation of any such changes is usually covered by in house procedures but the doccumentation provided by the vendor is usually the original version.

This may not be an issue with your particular Company but I thought it was worth mentioning.

Well Done
 
Thanks for the feedback.

Two clarifications,
Eric, Plain english can be determined by the non-technical guys.
Actually, it is to stop this stuff from being written in French or German, and to clarify part of the target audience for the FS.

to ndzied1, 5.5.3 means that we want the drive to defult to OFF when changed to manual or local modes (I think I will add this clarification to the document).

Doug
 

Similar Topics

Dear all, I have fx2n plc on my hand but I don't have the programming cable sc-09 and it would not be easy for me to get one. I need the cable...
Replies
3
Views
117
Hi all, i am the new controls guy at the plant and i have inherited a pc from the previous controls guy with Siemens tia portal version 16 and 17...
Replies
20
Views
903
I need to pull the program off of an old 90-30 so I can convert it to Allen Bradley. This is my first time messing with GE and I don't have the...
Replies
2
Views
87
New to vfds. I put in parameters. IP, but I get ethernet flashing and link solid. What did I do wrong?
Replies
9
Views
485
I'm been deciphering a program for a press here. I've gotten most of it deciphered using the manual to understand the instructions (first mitsu...
Replies
11
Views
325
Back
Top Bottom