PLC/program maintenance

[ValeoBill]

I'm looking for feedback from guys who work in an industrial environment. What type of PM work do you do with PLCs? I've worked in places that:
1 - Didn't allow program changes without Engineering approval.
2 - Any changes required written and/or electronic backup.
3 - Changes made with no documentation provided. As long as it works ...
I've been at this for 30+ years. I've worked with platforms that would lose their program at the slightest voltage drop and some newer stuff that I've never worried about.

Any input on the development and maintenance of these systems would be greatly appreciated. To be honest, I'm looking for some industrial consensus to show my "superiors".

 

[geniusintraining]

To be honest, I'm looking for some industrial consensus to show my "superiors".

Good luck!

I was at a customers 3 weeks ago... we had a conference call with their corporate engineering and they took pictures of the changes I made when I was doing them, they also had to do a verification test

I added a math overflow unlatch to LAD 2 and it took 20 seconds

There will never be a standard

 

[ValeoBill]

I'm not necessarily looking for a "company standard". Things that have proven useful and/or time saving either for yourself or people on other shifts to effectively communicate changes or procedures.

 

[plvlce]

I always save separate copies of the program immediately before and immediately after changes.

Generally I'd look to require engineering approval for any changes that aren't dealing with an immediate/urgent issue (and ones that are should be documented and gone over afterwards for approval).

 

[Jim3846]

Do a backup before any changes start and do make sure that you upload all the timer and data table values during the save.

When that engineer makes a change make sure its in the same version of software that your using, otherwise it will turn into a big slog to get your maint dept to new version.

Save the changes and upload all that data for the changes same as when you made the backup at start.

Btw, saving the data is somewhat easy on rockwell platform. But on a Step 5 or 7 type software you have that feature that it will only save 1 file in the program if you dont do it right. So make sure your saving everything.

Put a date at end of your file and keep it in same format that everyone agrees to.

MCP_A_20220208 <<< MCP and saved on year 2022, month Feb, Day 8.

Store it in some way where its backed up thru a corporate backup system. That way when your local copy is zapped you have a way to get a backup thru corp IT people.

Learn how to use the plc software compare function, so that you can see what the changes are if your interested.

 

[arpus4KM]

1) Keep backups and a Vault system... Programs should be able to be downloaded by anyone, but nobody should be able to update the latest version unless access is granted through password. And each version should be stored by date. This makes it easier to deal with a company with hundreds of machines that are all having small changes made, and its almost impossible to not having a working program or backup available, even when a computer dies.

2) Make sure to keep PCs up to date, and test online/download/upload/comms after each windows update, or downtime is going to happen.

3) Make sure each cabinet has a copy of the IO on a physical sheet, and possibly any 'Permissive' rungs printed out for a ready to run/safe signal for operation. These two things being available will prevent 90% of the maintenance people from wanting to get someone to bring a laptop to troubleshoot why something isn't working.

4) Make sure to keep cables labeled (for those who don't know exactly what to use on what), and in order. Can't count the number of times i needed a uic device, and somebody had used it and left it somewhere.

5) try to get people out of the habit of just flicking a keyswitch from prog to run when there's a fault. I've been called to a lot of places that say "The keyswitch isn't resetting it anymore, we need someone to get online and reset it". Then i let them know the program is lost, and they wonder why.

6) Actually replace batteries BEFORE the program is gone....

7) make sure any contactors/solenoids bigger than an Ice cube have an aux relay for activation so outputs don't get fried.



I'm sure there's lots more..... but anything and everything happens right.

If my old place of work had followed better standards, we wouldn't have been replacing IO cards and rewriting program changes so often.

 

[James Mcquade]

where we used to work, we used a vb script/macro in logix 500 & plc5 to do a timed backup as well as compare the master copy which only the IT department (we are the plc programmers) had access to.

where i am now, we use factory talk asset center to do the backups.
regards,
james

 

[willxfmr]

It really comes down to standards at each plant. Here we have a folder with the ACD file that is supposed to be copied to your desktop and opened from there. This means you always have a fail safe plan. This assumes that anyone that made a change saves the modified program to the folder as a new revision. In real life, that seldom happens.

As for who can make changes and under what circumstances. Here, we run on the "just make it work" system. Not ideal when our mechanics default answer to every problem is "must be something wrong with the program" We spend a lot of our time troubleshooting things to the point that we can point at one thing and tell the mechanics to change that one part. Otherwise, it's always a glitch in the program.

Other places I have worked, anyone with access could makes program changes, but if you weren't on "the approved list", there would be hell to pay if you made a change.

Bubba.

 

[Yacineg]

A revision number on the backup for all major changes will be life saving.

 

[saultgeorge]

To be honest, I'm looking for some industrial consensus to show my "superiors"....

It seems in the projects/employers I've worked with that there are "extremes".
One extreme is like those above have posted, the programmer does whatever possible to document changes, save by date/revision etc. and the customer doesn't really care.
An expample of the other extreme would be when I worked for an integrator at an OEM on a launch. After a certain point there were basically no laptops allowed in the plant. The contractors had login access priviledges to their system and any changes made would be kept in the system as a backup, person's name, time and what changes (rungs, instructions etc) were made. I kind of liked that, however it could be a pain if someone else had a program open. There were many such stations throughout general assembly and body shop.

 

[geniusintraining]

Back in the day... I tried everything

I left a thumb drive in the cabinet and asked updates be put on the drive
We had one laptop for maintenance
Built a website for engineering/maintenance so note could be keep about changes
Had a PLC program that was implemented that would compare programs every 90 days
So on and so on

I never found anything that would work, most people either dont care enough, dont have the time or just lack the ability to do what they should

This is/was the reason for my comment about good luck yesterday, once you get management talk into a 'best practice' then the real work begins and you need everyone to do it.

Maybe if you were a small shop and only one or two shifts but its really hard when you have 40 people spread out running 24/7

 

[Frost999]

I'm not necessarily looking for a "company standard". Things that have proven useful and/or time saving either for yourself or people on other shifts to effectively communicate changes or procedures.

FT Asset center can largely handle user rights and has a place for revision notes that can be seen, along with a list of dates of revisions.

 

[JLand]

FTAssetCentre or any similar revision control and disaster recovery software is an absolute must in any plant of significant size. This includes mandatory descriptive commenting and comment auditing. If you can get process engineering on-board, it makes MOC a lot simpler (not replacing MOC though) because if odd behavior is observed you can easily see exactly what changed, negating the need for taking screenshots of every rung you edited or saving the PLC with a new version number every time you make a tiny change.

 

[arpus4KM]

Basically, Controlling programs/updates/changes is like trying to make sure all the wires get put back in the tray and the panduit covers go back on....

Good luck!

 

[mylespetro]

Basically, Controlling programs/updates/changes is like trying to make sure all the wires get put back in the tray and the panduit covers go back on....

Good luck!

Also known as "things that never happen."