Controllogix I/O ladder question

[moltra]

I am making some changes in a control logix PLC program that an engineering programmed for my company. In the program they have used the same I/O points in differnet tasks. I have noticed that some of them are overridding others and not letting the program operate as designed. I am trying to consolidate the I/O points so that there is only one instance of each I/O point in the program.

I am trying to figure out if I should have a seperate I/O section or have all the I/O in the main program (routine/task).

what has everyone else done when faced with this?

 

[rdrast]

A valid answer would depend on what the program is supposed to do. Are the duplicated I/O points (and I'll assume you mainly mean Output's) in mutually exclusive sections of code? Are the just errors?

There are all sorts of different program styles for Logix. I give the physical I/O aliases in the local 'task' that they are used in. I also just directly copy inputs to various UDT's at the beginning of a 'section' of code, do my logic based entirely on the UDT's (which I generally put in Controller Scope for easy access by HMI's), then drive a single physical output from the end result of my logic done with the UDT's.

Some people do sort of the same, but make one specific "Physical Input" and on specific "Physical Output" routines. Some people copy all inputs to an array of DINTs and call it "I", because of familiarity with PLC/SLC/Micro structures.

All that aside, addressing duplicate outputs (normal OTE's) in different tasks is probably not a wise idea, unless there is a clear differentiation between the tasks, such as "Task_Automatic_Mode" and "Task_Manual_Mode", which are mutually exclusive.

If the outputs are latch instructions, (OTL/OTU) then duplicate (even multiple duplicate) output instructions may or may not be a problem.

 

[moltra]

No the code are in different task that run at the same time, and the programmer used multiple instances of both I/O in the different tasks.

I am moving all the I/O into the Main task and combining all the affected lines.

 

[Ron Beaufort]

everything that my distinguished colleague rdrast said is right on target ...

I am moving all the I/O into the Main task and combining all the affected lines.

that approach sounds fine on the surface, but here's a suggestion before you go too much further ... as long as the program isn't "trade secret" or "proprietary" information, why don't you post the .ACD file and let us take a look at it for you? ... we might be able to spot something that you've missed ...

 

[moltra]

I will post 2 versions of the file the emulate one is the one that I am currently working on. fixing some of the I/O problems and getting the manual controls working.I also added the RSview ME files. there is 7 conveyor belts controlled by this program normally in automatic all belts run at the same speed, manual is to clear jams and things like that.

 

[Ron Beaufort]

Greetings moltra ...



you said:

the programmer used multiple instances of both I/O in the different tasks

unfortunately I’ve only had a few seconds (in between work for my bo$$) to look through the first program that you posted -... so far I haven’t found any obvious instance where a “real-world” output point is being used in more than one place ... quite possibly I’m just misunderstanding what you’re saying ... is there a specific I/O point that you’re having trouble with that you could give as an example? ... if so, I’ll be glad to try to track down its operation ...



in the meantime, I did find a few things that might add to the discussion ... if I understand correctly, you mentioned having trouble getting the manual controls to work ... notice in the figure below that the task for “Manual_Control_of_Conveyors” has been inhibited (disabled) ... now you’ve probably already noticed that - so no offense intended ... I’m just trying to bring up some ideas that might be helpful ...

another thing that I find “odd” is the very high Watchdog setting that has been specified for each of the tasks that I’ve looked at so far ... basically your processor has been given a full 15 seconds of time in which to execute each one of its periodic tasks ... that is certainly not a “common” setting ... the default setting of 500 milliseconds is much more common and should be adequate ... the much higher watchdog settings shouldn’t cause anything to “not work” - but the fact that they’ve been set so high, makes us wonder if maybe the original programmer misunderstood their intended use ...



also ... many (most?) programmers would have put much (all?) of the type of “manual control” code in the project’s “continuous task” and not placed it in a periodic task instead ... it’s really hard to imagine why the logic for the “manual control” of a system should have the type of “periodic time-critical” operation that usually goes along with a periodic task setup ... “continuous” operation would be much more common ...



just as a “plan of attack” I’d recommend moving the “manual control” logic into the “continuous task” and see if that helps ... then again, that’s probably exactly the course of action you mentioned that you were going to try next ...



please keep us posted on your progress ... I’ll look into this some more later as time permits ... probably you or some of the other forum members will have this all nailed down before I get a chance to dig into it ...



hope this helps ... wish I had more time ...

 

[moltra]

yes the manual code is inhibited because I am still programming.

Look at the outputs to the drives and to clear the faults.
the high watch dog timer I set because when I 1st got the program it had the PF 700 RFP interval set for 5ms, and the fault task set to 5ms and the main routine task set as a continuous task, so the plc kept stopping the main routine to run the fault task which would cause the machine to stop, because all 7 drives would not get the start command. It is very critical for all 7 drives to start at the same time. And to stop at the same time.

This fast RFP of the PF 700 caused Comm failures.

As for the duplicate I/O look at:
Searching through MainProgram - MainRoutine...

Found: Rung 3, OTE, Operand 0: OTE(Drive1:O.ClearFault)

Searching through MainProgram - Startup...

Searching through fault_handling - fault_handling...

Found: Rung 44, OTE, Operand 0: OTE(Drive1:O.ClearFault)

This PLC is interfaced with a Panelview 700 and gets some of its signals from an old german PLC. The engineering company's wiring diagrams, had the 120Volt input for the new PLC for the run command comming off a relay that was controlled from the old PLC, but there was NO voltage on the relay contacts. I had to rewire it the day we put it in service to get it to work.

Those are some of the bugs that I had to get out of the program when I was given it by the engineering firm.

 

[kamenges]

If this is a typical example you may be trying to treat the symptom, not the disease.

The double reference you list has one reference in the main routine and the other in the fault handler. Why is your program constantly entering the fault handler? If you correct that the double reference is more or less a non-issue. Ideally, your machine would be executing a controlled, if rather quick, stop if a program fault were to occur. So if you are not going to allow the processor to simply enter fault mode on a fault you need to indicate that you have run the fault routine and handle the plc logic accordingly.

A case could be made that the use of the fault routine in this case may not be what the original programmer had in mind. The fault routine should only run on a program fault. You should get most of these doctored up as a result of general troubleshooting. If you get a hardware fault the fault routine will not run, as far as I can tell.

The reason for the double reference is, if the processor is allowed to fault, no other logic will run after the fault routine. So even if you consolidate the logic in the main routine ti won't run on a fault. I'm sure the original programmer did this to make sure the drives shut down on a plc fault. I haven't looked at your program yet (sorry) but if the machine uses one of the typical AB fieldbuses (Ethernet/IP, DeviceNet, ControlNet, Remote I/O) the drives will most likely shut dowen as soon as the plc drops out of run anyway. If they don't you need something like this to make sure your machine stops on a fault.

Keith

 

[moltra]

The word fault is this case is not a fault of the PLC but a fault in one of the PF 700 drives.

 

[Ken Roach]

The first is: Never get involved in a land war in Asia

There are a handful of classic blunders evident in this program, especially the "treating the symptoms, not the problem" fallacy.

Let's make it clear that the "fault_routine" is not in fact the controller's Fault Handler, but rather a routine put into the controller to diagnose or catch an instance where the drives failed to start when commanded.

Your statement "This fast RPI of the PF 700 caused Comm failures." was a red flag for me.

No, it didn't.

You may have some Ethernet noise problems caused by careless installation, but that's a separate problem.

The fast RPI did not cause communication failures to the drive. Rather, it made a common programming mistake for networked drives appear more often.

Let's call it the "Simultaneous Command Effect".

The basis of this effect is that ControlLogix I/O updates are asynchronous to the program scan. They can even happen in the middle of a rung's execution.

A-B drives on a network are commanded to start by a false-to-true transition of the Start bit. When this transition occurs, the Stop bit must be false. The drive will stop any time the Stop bit is true.

It's distressingly common to see a simplistic rung written to control the Stop bit:

Start Stop
--]/[-------( )--

While this seems perfectly logically valid, what happens when the I/O update occurs in between the evaluation of the Start and the Stop bits ?

(to be continued)

 

[moltra]

that is why I come to this site. I have used a lot of PLC 5 and SLCs but this is the 1st time I have used a COntrollogix and PF drives over a network.

Actually we did have some network noise due to using non shielded cables.

 

[Ken Roach]

The answer: The Stop and Start bits are both true when the I/O connection data arrives at the drive. Because the Stop bit is still 1 when the Start bit goes from 0 -> 1, the drive doesn't start.

Any time I see a "Start failure timer" or other construct in a program I know that this problem is rearing its ugly head.

In your program, the Start bit can be set several rungs before the Stop bit is evaluated. This is plenty of time for the I/O update to occur. In fact, the faster the I/O update (the lower RPI values) the higher probability that this will happen.

So how do we fix it ?

(hint; slowing down the RPI only reduces the frequency of the problem, but does not eliminate it.)

One method is to not use the I/O connection data tags directly, but rather to use a tag with the same structure and copy the data into the actual I/O tags at the end of the program control routine. This is what we do almost all the time with DeviceNet-connected drives.

Another method is to only turn on the Stop bit until the drive has actually stopped. I use the ".Active" bit for this. Once the drive stops (as long as it's not coasting to a stop) the Active bit goes false, making the Stop bit go false, and the drive is ready for it's Start bit again.

That's the most effective method I've used in this kind of application.

You might also try checking the "disable automatic output processing" selection in the Control task configuration, and putting a Immediate Output (IOT) instruction at the end of the Control task's Main Program for each of the seven drives.

Once you have done one of these things, try turning those drive RPI values back down.

 

[Ken Roach]

You know what ? Don't take the above as gospel. I have definitely used the .Active bit to prevent "fail to start" events in the past, but I'm not completely sure that my reasoning on the output data timing is correct. Time to go scratch my head a little more.

 

[moltra]

Your statement "This fast RPI of the PF 700 caused Comm failures." was a red flag for me.

No, it didn't.

You may have some Ethernet noise problems caused by careless installation, but that's a separate problem.

The fast RPI did not cause communication failures to the drive. Rather, it made a common programming mistake for networked drives appear more often.

Let's call it the "Simultaneous Command Effect".

QUOTE]

Actually it did give me communications fault. I was getting over 30,000 EN Rx overruns every day. I changed the RPI and it dropped to about 10 a day. I was getting about 25 missed IO Pkts a hour, now I get maybe one a day

 

[OZEE]

Your statement "This fast RPI of the PF 700 caused Comm failures." was a red flag for me.

No, it didn't.

You may have some Ethernet noise problems caused by careless installation, but that's a separate problem.

The fast RPI did not cause communication failures to the drive. Rather, it made a common programming mistake for networked drives appear more often.

Let's call it the "Simultaneous Command Effect".

Actually it did give me communications fault. I was getting over 30,000 EN Rx overruns every day. I changed the RPI and it dropped to about 10 a day. I was getting about 25 missed IO Pkts a hour, now I get maybe one a day

You were getting those failures because of comm problems (noise, connections, etc.) - not because of the RPI. Changing the RPI only changed how often the errors were encountered. Reread what Ken wrote -- I marked the important clue... I would almost bet that you have at least one of the following:

• loose connections
• bad terminations
• missing/wrong terminating resistors
• comm wires running along with / parallel to motor leads