Reoccuring "freeze" on micrologix 1100

Greetings,
I have a piece of equipment that went down last night. An operator crashed a hydraulic ram into a prox sensor. The guys put a new, correctly spec'd, sensor and tried to run. The machine has two rams with multiple prox and fiberoptics to verify part position. The incident was on the second ram which is a separate cycle that can only be ran after the first cycle is complete. Once the first cycle was completed, the program skipped the first couple of steps for the second cycle and locks up with a panelview message display that cannot be satisfied. Everything would reset and the first cycle would work just fine and then the same thing. I came in and after checking things over I downloaded a backup of the program and voila, it works fine. The next day the operator tripped the light curtain while pressing on the second cycle and the same problem came back. We reset to home, nothing.
Cycled power, nothing.
Redownloaded the same program and it works.
We can duplicate the problem every time we break the STI light curtain in the second cycle. Obviously, we will try not to touch the stove that is hot, but it will happen again. This piece of equipment has ran for five years and this is the first we've seen this.
Thanks

This sounds like a programming problem, not something wrong with the Micrologix. I would suggest going online with the controller to verify that it stays in run mode, then recreate the symptom while monitoring it to track down the root cause.

Is the program getting dumped?
I had a weird one with the MSG instruction. I tired to create one while online in run mode and it took it, then locked up the processor. You have to do that one offline and download it.
Maybe you have power issues that it just can't handle. After 5 years you'd think you'd know if there was a programming issue.

After 5 years you'd think you'd know if there was a programming issue.

Click to expand...

Perhaps, it all depends on whether all functions were completely tested to ensure operation.

Another thing it could be, if a download clears it, is it possible that there are values in registers that are stored in the offline copy of the file, that are somehow modified during certain conditions (Light Curtain trip for example) & the correct sequence for recoving is either not followed or not coded correctly.
I would be focusing around the code in the 2nd cycle to do with the light curtain (post a cut here if you can).
Then looking at what the offline version is reading compared to the online version after the 'freeze'.

Just to be sure, the ML1100 is staying in run mode throughout the entire cycle, just the sequence does not continue & then the PV conditions are not met?

Im thinking its the registers reseting as well, my inexperience requires me to ask the best place to compare the registers of the upload of the program in the bad state vs. the backup. I will post a copy of the rungs when I get back in, it has 7 files jumping around a bit so its purty fun to look at. thanks

If you zip the program (right click, add to compressed file) and post the .zip file here attached to a post, we can help you look for potential problems.

You can use the Compare tool to compare data tables. In RSLogix500, on the main menu click "Tools" then "Compare..."

Thank you, I had found the compare function and was using it when you posted, really cool. Noticed a significant problem with the integer N7:111, its about 256 when its value should be between 0-15. Here's a zip of the program.
thanks

Noticed a significant problem with the integer N7:111, its about 256 when its value should be between 0-15.

Click to expand...

N7:111 looks like it is being used as an Message Word, presumably to an HMI. It is being set at the Bit level, so it could conceivably have a value much higher than 256. Remember, each bit has a Binary Weight, when converted to Decimal.

Stu....

I'm sorry but may I get a little more clarification on that? This is definetly something I don't fully grasp. The HMI(PV600) is looking for an unsigned integer, prompting a message display between 0-15. In RSLogix 500, when you use an instruction such as a MOV or an ADD to write to an N7 the number that is in that instruction is the same as the corresponding message display. I have read a little about hexidecimal and other basic level math. I do understand the idea that it needs to be converted for the physical layer, but I guess I'd like to be able to figure out what 256 at that address represents.

I guess I'd like to be able to figure out what 256 at that address represents.

Click to expand...

Think "Binary" What bit in that word would have to be a one to give you a value of 256. See picture below.

Condition bits are being set in N7:111 through N7:113.

Ladder 7 rungs 45-50 are scanning through these words using N7:109 as an indirect value. You may notice that, in this save, it was at 8, the index as the lone set bit in N7:11 through N7:113.

When the scanning routine encounters a bit (rung 49) it copies the value in N7:109 to N7:110.

I am presuming that N7:110 is the value the HMI monitors to display a proper message.

This routine will allow display of more than one condition at 4 second intervals (T4:3 plus T4:4)

So, it s perfectly valid for one or multiple bits to be ON in N7:111 through N7:113

Investigate the condition in Ladder 7 Rung 16. 'Remove Retainer Clip From Pick Bin'

This helps alot, I think I'm starting to connect some of nodes in different corners of my brain. The word is the sixteen bits at a given address, in my case n7:111. the zeros to the left of the one are not looked at so 100000000 is 256. n7:110 is 1000 which is 8. My dad did tell once that there are 10 types of people those that get binary and those that don't. Still wondering why, when I reset via the HMI and rehome the equipment, the program scan "jumps" past the first few rungs on file 4. When I redownload the program the problem goes away. I have compared the programs and am unable to find it. I guess I need to find what is not being reset with the currently programmed reset?