AB PLC 5/40B crashes during analog configuration


Thread Starter

Mark K

We're running the latest version of RSLogix5 English, 5.00.01, and use 5/40B processors. If we make an on-line change to an analog scaling value, accept the edit, then download the changes, sometimes the processor crashes. We're at the point were we can no longer do on-line analog work while our mill is running for fear of crashing the process. The crashes also happened with previous RSLogix 5 version 4.10.01.

We used to use Rockwell's Wintelligent Logic 5 software v.3.23.00 and still have it on one pc. We can use it to do on-line analog work till the cows come home without a problem. It's only since we switched to RSLogix5 that these crashes have been happening.

Has anyone else out there experienced the same problem? Is there a fix?
How old are your PLC5s. A few years ago AB had to update the PLC5 firmware because of a glitch that would occur when there was alot of block transfers occuring, especially if STI's were also in use. I don't remember all the details, but the processor would hang and leave IO in the last state. If your scaling is done in module, depending on your programming techniques, that could change the size of the block transfer (heence traffic) as the processor writes the new configuration to the module. Check with AB tech support.
I didn't use analogs on PLC5 but I have lots of experience with analog on SLC. The problem is if your setting of the analog point cause overflow or out_of_range errors (both faulting CPU).
Quick and simple fix is to put rung that clears these faults just before end of the progrma (this type of faults is checked after succesfull scan).
So :
Find some time to try it out and see what is the error (S:....) amd simply unlatch it in last rung...

OK, but that still begs the question. Why does it only happen with RSLogix 5 and not Wintellignet 5? We've talked to AB tech support and they're not sure what's wrong.

Daniel C. Rozok

We had a simular problem with RSLogix English v3.02 with the analog configuration and adjustments to scaling values. After a change in analog
scaling, accepting the edit, and then during the downloading of changes we
lost communication to the processor. PLC-5/40B ran OK, no issues. After
reconnecting to processor and examining analog configuration data, changes
had not been made.

No problem, we thought, adjust values, accept edits, and download. We did
this but changes were not being accepted. No errors, no messages, no
confirmations. If you monitored values, the live data worked, but the
scaling was incorrect due to the PLC not accepting the adjust scaling values
from RSLogix.

The only way that I was able to solve this problem, was to delete the data
file were the configuration information was stored, and re-build.
Thereafter, I was able to download, on-line, and the PLC accepted the
changes. Simular, and maybe by deleting and recreating the configuration
information wihtin your processor may clean up your problem.

BTW, don't zero the values, as this did not solve the problem. By actually
removing the data elements from the application and then adding back, seemed
to solve the problem.

Daniel C. Rozok

Bob Desrochers

The processor should give you an indication of why or where the fault occurred in the processor status folder.
(while the machine is still faulted)
This should give you sufficient clues to resolve the problem permanently. I have seen memory allocation issues with analog cards that only show up during a card configuration change download.



Dave Reading

On line editing requires several steps. Start on line editing, accept edits, test edits. At this point you can try things and see if they are working. If they are working you then have to assemble edits. Then while still on line be sure to save the project WHILE STILL ON LINE. This does two things. It gives you a current copy of PLC program actually being used and also allows RS Logix to find the file when you try to go on line again. If you make changes while off line be sure to download the new program before going on line. I'm not an expert but these things are necessary and do work.
That's correct but unfortunately when our processor crashes we can no longer get back on line to see what's wrong. Only after cycling power can we communicate with the processor. By cycling power we reset the fault! It's a catch 22!
Had nearly the same problem after upgrading to RSLogix 5 5.00.01, and it turned out to be a bug in the cross-referencing. I disabled the cross-reference in RSLogix, and all is well. They're supposedly fixing it.