Control logix Processor

V

Thread Starter

Vijay Bharadva

I wonder if anybody can help in above subject. I am using 1756-L61 processor in one of our application. By some reason it is loosing the program stored in its compact flash RAM. In this condition if you go online with the processor, it is showing major fault in the processor. I checked in the major fault tab of the controller properties in RSLogix 5K and it is showing code 60 type 1 unrecoverable fault.
If you clear the fault and download the program again, it is working for some days and same fault is happening again.

Amazing thing in this problem is it is happening only at one stage of the machine operation. i.e. certain operation is running and certain parts of the machine is in specific position.

If anybody know about this problem please let me know as early as possible. my email id is vijay.bhardava [at] dunlop.co.za
 
D

David Ferguson

I have had a similar problem, there is a service bulletin on their website concerning ADMUL (I think spelled right) chipsets of a certain date on the processor. They do what you describe.

Mine does the same thing but misses the recall date by one month so I am out of luck and must buy a new processor.........great.

Hope this helps....

Dave Ferguson
Control Systems Engineer
 
V

Vijay Bharadva

Hi Dave,
I already checked all of these and changed the processor also. still it is happening.
 
J
I had similar problem. I asked Rockwell and this is answer:

"Problem was due to customer accidentally programming a jump to subroutine jsr which jumped into itself. Cured by reprogramming jsr to jump to another routine."

But it confusing me a bit. I don't understand this answer. Can anyone clear me it?

Than you


 
W

William Sturm

It sounds like you had the subroutine calling itself. This will create an endless loop unless you have some conditions on the JSR which limit the number of times it will be true.

Bill Sturm
 
J

Jeremy Pollard

A JSR (jump to subroutine) targets the first rung in the program file... so if you are already in that program file, then you will simply restart the scan at the first rung, then hit the JSR again and repeat until the watchdog times out!!

Cheers from :
Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline[.]com
Control Design www[.]controldesignmag[.]com
Manufacturing Automation www[.]automationmag[.]com
3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
 
I can't say how this caused your problem, but the explanation you gave was that a subroutine called itself. This is what is known as "recursion". It is somewhat like a loop, except that it has some additional complications.

Each time a subroutine is called, the location for the subroutine which called it must be stored somewhere so that it can return to where it was called from. For example, if subroutine A calls subroutine B, then subroutine B must somehow know that it has to return to A (and where in A) when it is done.

The usual way of dealing with this is to store the location on a stack. That means that each subroutine call consumes a certain amount of memory at the time of the call. If the call nesting level gets too deep, you will consume all the available memory which has been allocated for the stack. This is called a "stack overflow". If a subroutine calls itself with no limit on how many times this happens without returning, then this is known as "infinite recursion", and a stack overflow results.

A stack overflow should simply cause the processor to fault when the firmware detects that the limit has been reached. However, if there are bugs in AB's firmware (and there are no doubt many bugs in every PLC), then a stack overflow could overwrite other areas of memory and cause additional problems.
 
If you can load a different/simple ladder logic program into the c*logix (preferably an example program from AB), and if it runs OK for an extended period of time, then I'd start to get real suspicious that the problem is based in the logic that you have written.
 
Thank you very much for all answers. Here are my new experiences:

1. I test simply program construction: in subroutine call itself. The processor fault is another:
(Type 04) Program Fault (can be trapped by a fault routine)
(Code 84) Stack overflow. Stack too small to perform operation.

2. I test the program with another ControlLogix processor. But the fault was same.

3. I check all routines with jsr instruction in my program and there is no routine call itself.

4. Time from program start to fault was from 15 s to 1/2 h approximately.

5. I try to compact project file and IT HELP me. Now it seems OK.

Thank you again for your answers and have a nice time.
 
V

Vijay Bharadva

Dear All,

Thank you very much for your response. Up to now I found following things in the processor.

1. There was nothing wrong with the firmware of the controller.

2. Atmel chip is looking alright in the processor PCB.

3 There was no recursion occurred in the processor programming.

4. There was a fault in the calculation in one of the rung. It was generating minor error (arithmetic overflow). expression was [value x (real) * -130 = value Y (int)] sometimes the expression value was going beyond the integer limit and it was generating minor errors. Number of minor error generation was tremendous (approx 100 errors per second). Now if these number of errors are going beyond certain amount then I think some memory is getting full in the processor and then if that memory is overflow then processor is confused. At this stage it can generate major error and it flashes the compact flash.
After I corrected the logic it is looking like behaving.

so if it is happening you all can try to find above bug also in your program.

If anybody experiences the same problem of the processor please share your experience.
 
Top