CLX dumps program when power lost during trending
- Thread starter AJZ
- Start date
cbeck77
Member
Is the battery connected or any good?
Contr_Conn
Member
You need to contact techsupport for instructions on how to extract fault log that they will analyze. Make sure yuou are running the latest FW available for ver 12 - check website
Operaghost
Member
So, to answer your question, no, that is not normal. As mentioned, check that battery.
Can you tell us which CPU you are using (550, 5555, etc...) and what firmware rev (12.04)?
OG
Can you tell us which CPU you are using (550, 5555, etc...) and what firmware rev (12.04)?
OG
Francie Bellew
Member
Hard to know without CPU specifics firmware rev etc.It shouldnt. I have performed this using 5555 and never encountered this problem while cycling the power. Have you contacted RS?
TimWilborne
Lifetime Supporting Member
We're not going to be able to help you on this one. Follow Contr_Conn's instructionsContr_Conn said:
Peter Nachtwey
Member
I am curious. Does this happen at 3, 4 or 5 milliseconds?
To do sampling at millisecond intervals the CLX must be using interrupts. It is possible that the interrupts arrive faster than they can be processed. This would cause a stack crash because an interrupt causes the processor to store the current state on the stack and then execute the interrupt. When returning from the interrupt the state is popped off the stack but if another interrupt arrives before the state is popped off the stack then two states are are stored on the stack. If this happens mulitple times then the stack will grow and grow until it overflows. Increasing the time between the interrupts will allow the previous state to be popped off the stack before the next interrupt.
To do sampling at millisecond intervals the CLX must be using interrupts. It is possible that the interrupts arrive faster than they can be processed. This would cause a stack crash because an interrupt causes the processor to store the current state on the stack and then execute the interrupt. When returning from the interrupt the state is popped off the stack but if another interrupt arrives before the state is popped off the stack then two states are are stored on the stack. If this happens mulitple times then the stack will grow and grow until it overflows. Increasing the time between the interrupts will allow the previous state to be popped off the stack before the next interrupt.
kamenges
Member
Apparently the processor only took a digger when power was lost. up to that time trending was moving along without an issue. If this was a stack overflow I wouldn't expect it to be tied to a power loss. Unless the contention is that the fault just happened to occur at the instant of power loss (that is, power loss causing the issue is a bad cause/effect relationship).
Keith
Keith
Black Jack
Member
I have seen CLGX processors lose the program before.
Usually the issue is the PLC detects some type of corrupt program problem and the way hardware is set up it clears the memory to make sure it is not executing a corrupt program. This unfortunately has nothing to do with the battery.
The really strange thing is I've seen it happen even when no program edits are active and nobody is even on-line with the PLC. I have asked Rockwell about it and have never got a solid answer. They request the diagnostic information (fault logs, etc)to troubleshoot the issue. Another possibility is a power spike that corrupts the program. Make sure you have a line filter on the incoming power to the PLC. I always use line filters to prevent this type of issue.
The good news is I have not seen it happen in a few years.
Usually the issue is the PLC detects some type of corrupt program problem and the way hardware is set up it clears the memory to make sure it is not executing a corrupt program. This unfortunately has nothing to do with the battery.
The really strange thing is I've seen it happen even when no program edits are active and nobody is even on-line with the PLC. I have asked Rockwell about it and have never got a solid answer. They request the diagnostic information (fault logs, etc)to troubleshoot the issue. Another possibility is a power spike that corrupts the program. Make sure you have a line filter on the incoming power to the PLC. I always use line filters to prevent this type of issue.
The good news is I have not seen it happen in a few years.
Similar Topics
Controller: 1756-L84E v.35
Prosoft MVI56E-MNETC for ModbusTCP/IP
I'm having an issue with some of my write commands. The write command that...
I have several Avery scale units and they are configured as Generic Ethernet modules, and I am actually reading the data fine for the weight...
What's the best way to move a tag value from the panelview+7 to the clx plc. We display amps from a power meter on the panelview screen, read in...
I'm running into an issue migrating a PLC-5 using the newer Logix Designer Export when opening a saved .ACD from RSLogix-5.
It has multiple RIO...
We have two sites that are stranded with no line of site, they are handled by phone/modem with a chain that includes:
Stranded site (client)...
