PLC-5 Is it possible to make individual Ladders read only or password Proteced?

Is it possible to make individual Ladders read only or password protected?

I'm not even sure I want this, but I'm trying to solve a problem.

Right now onsite electricians are able to edit our logic. I don't intend to take this away from them.

What I'm doing is having our inputs go to bits and our ouputs come from bits on one ladder. This way you don't have to make five edits to the program just to bypass one faulty plugged chute switch, and then lose track of half of them when the switch is fixed.

If I know some logic is correct, and it's rather complex, I'd like the power to lock it down until I'm consulted about changes.

it's possible ... now whether it's a "good idea" - or turns out to be opening a "can of worms" remains to be seen ...

make five edits to the program just to bypass one faulty plugged chute switch

Click to expand...

if I understand what you're saying here (I'm not 100% sure that I do) but many (most?) folks would tend to FORCE the chute switch on, rather than change the logic to "bypass" the switch ... then again, "forcing" often turns out to be opening another equally icky "can of worms" ...
.

Ron Beaufort said:

it's possible ...

Click to expand...

Learn something new everyday

Ron Beaufort said:

if I understand what you're saying here (I'm not 100% sure that I do) but many (most?) folks would tend to FORCE the chute switch on, rather than change the logic to "bypass" the switch ... then again, "forcing" often turns out to be opening another equally icky "can of worms" ...
.

Click to expand...

Not to try to open that can of worms, but I always felt that if you weren't checking change of state on all inputs, then the input didn't really serve a purpose, because you couldn't tell if it work working or not. Forcing an input on and leaving it on would make all of my programs no longer work.

Greetings Tharon ...

first let me say that I personally am not a big fan of FORCES ... but I do have to explain to a lot of people how they work – because I know that the critters WILL be encountered in the field ...

so ...

it seems like you and I are on the same page as being "not too impressed with forces" ...

but ...

I'm going to admit that I am thoroughly confused by your statement:

but I always felt that if you weren't checking change of state on all inputs, then the input didn't really serve a purpose, because you couldn't tell if it work working or not. Forcing an input on and leaving it on would make all of my programs no longer work.

Click to expand...

I'm honestly interested in what you mean by "checking change of state on all inputs" ... can you give us a simple example of how you're doing that? ...

once again, I'm not trying to debate the "good, bad or ugly" aspects of forces ... but I'm quite ready to learn something new here if you've got a useful trick up your sleeve ...

going a little bit further, I "THINK" that the OP was talking about his technicians using an unconditional branch around an input to "bypass" a false condition ... (some folks call this "strapping out" an input) ... once again, I don't have to personally like that approach – or use it – I just have to explain it ... AND ... if the OP's troublesome input happened to appear in several places in his code, then several "straps" or "bypass" branches would be necessary ... in that respect, just one properly applied force should take care of all of the "bypasses" - and be easily removed once the bypasses were no longer needed ...

What I mean is that if an input is used in the program, I always check to make sure it turns both on and off during the cycle, or during its operation

Cycle start push buttons are checked to be off before the cycle completes.
Sensors that prove a part is in place are checked to be off to prove the part is removed.
Sensors that prove a motion has happened, are checked to be off to prove that a motion has not happened (or that the opposite / counteraction has occured).

If your input is only ever checked to be true, then you don't really know it's working. Somewhere in the program it should be checked to be false. I've seen many programs were (as a simple example) the Extend and Retract of a cylinder motion are checked with two switches. But the sensor fails in the on state, or shorts, and it continues to run because the retracted state was only checking for the retracted sensor to be on, and vice versa.

Now, it gets a bit more complicated with some types of inputs, and with all things, it likely doesn't work with every possible input setup. But for the vast majority of inputs on my projects, if you were to force it "ON" you would have to remove the force or force it back "OFF" sometime later in the program or else it wouldn't continue the sequence or process.

(I also don't like high/low limit switches which are never activated during normal cycles, and may never be activated for the life of the machine, because I can never tell if they would actually work when needed 5 years down the road).

it likely doesn't work with every possible input setup.

Click to expand...

OK - that's the piece of the puzzle that I was looking for ... you can't do it on EVERYTHING ...

be safe ...

Ron Beaufort said:

OK - that's the piece of the puzzle that I was looking for ... you can't do it on EVERYTHING ...

be safe ...

Click to expand...

When I sit down with the design guys on a machine, I try to stress on them my (negative) opinion on any sensors or switches that remain on or off the entire time by design. And always try to come up with a solution that involves change of state.

So far there are a very select few instances where it can't be done. And I begrudgingly accept them and stress to the designers that I cannot ensure the operation of the switch through my program alone.

Edit:
I guess back to the original reason I posted, if someone were to attempt to bypass an input on the field in one of my programs, I would expect it to take multiple rung edits, rather than a simple Force ON, because the Force ON would not bypass it in my programs.

Ron Beaufort said:

it's possible ... now whether it's a "good idea" - or turns out to be opening a "can of worms" remains to be seen ...



if I understand what you're saying here (I'm not 100% sure that I do) but many (most?) folks would tend to FORCE the chute switch on, rather than change the logic to "bypass" the switch ... then again, "forcing" often turns out to be opening another equally icky "can of worms" ...
.

Click to expand...

Compass

As Ron has shown it is possible to control access to each routine and I also wanted to add that depending on your needs you could give access to the routine but control what the person does by their login credentials on a very granular level using Factory Talk Security. You could do things such as prevent the changing of forces and may other things.

The links below are very good resources if Factory Talk Security could benefit your situation

http://literature.rockwellautomation.com/idc/groups/literature/documents/gr/lg5-gr002_-en-p.pdf

http://literature.rockwellautomation.com/idc/groups/literature/documents/qs/ftsec-qs001_-en-e.pdf