Help needed about 1771 IFE-A . Urgent .. Please....

hitit

Member
Join Date
Jun 2002
Posts
13
Hi everybody,
we have an Allen-Bradley PLC5 based automation system in a sugar factory which has been working properly since 1999. ( sugar factories work only 4 or 5 months in a year in Turkey, so was our system... )
there was no problem for 3 years.. but this year , 3 days after the the start-up , 4 analog modules stopped reading analog values from the field suddenly.they're now keeping their last values before this strange error occured.in fact there are 13 analog modules. these faulties are IFE-A series modules , the others are IFE-C..
My collagues have gone there , and looked for some extraordinary things that can cause such kind of trouble.
BTR and BTW's are OK. 4-20 mA current flows through the channels of the modules. Other series of modules in the same chassis are reading all the values needed. There is no communication problem. Processor status is OK.. Checksum is done.. i mean it's OK too.
Unfortunately the values are still and always stable .
Is there anybody who will be able to give some answers or remedies or at least ideas about the problem ?.. Did anybody encounter such kind of thing before?

Will you please help us ? Because of these deaf modules 30 percent of the plant is being run manually.. it is a very awfull situation..

i am waiting for your immediate answers...
thanks in advance..
 
My best guess based on what you've said: the block transfers are not being executed properly.

You say that the Block Transfers are OK - are you sure that they are being executed? Hint: put a temporary "test" rung immediately after your block transfer rungs. Make this an unconditional rung with an OTE to control a spare binary bit. Since the rung is unconditional, this spare "test" bit should always be on. If you are able to "toggle" this bit off, then this section of ladder is NOT being scanned - even if the "power rails" at the left and right sides of the screen are green.

If "block-transfers-not-being-scanned" is NOT your problem, can you zip your program file and post it? Maybe one of us could spot some detail that your colleagues have missed. Be sure to include a note as to which modules are working - and which ones are not.

Good luck.
 
Take a very close look at those block transfer instructions. 1771-IFE analog input modules changed a little bit when their hardware was revised for Series C. One the changes is that they have extra words available in their Block Transfer data tables for over-range, under-range, and calibration data.

If your Block Transfers are all configured to use the larger data tables for the Series C modules, but some of the modules are Series A, then those block transfers intructions will fail and return an error code (look for a negative value in the Length reply; that's the error code).

The next thing to check is the source data for the Configuration blocks that are being sent to the 1771-IFE modules via Block Transfer Write (BTW) instructions. If the bits set in those files have changed from their proper settings, the IFE modules may not be getting the configuration they need to properly return the analog values you want.

You may want to physically examine the modules; there are setup jumpers that are different on Series A and Series C modules; if any of these were swapped between chassis, the tech who did it may not have set up the new modules to match the signals to which they are connected.

For details on the block transfer length and contents, as well as the differences between Series A and Series C of the 1771-IFE module, examine Chapter 3 and Appendix B of this manual:

1771-6.5.115
 
Last edited:
(sorry, guys, I'm not trying to turn this into an A-B technical support forum, but our querent sounds like he needs local help too)

Rockwell Otomasyon Tic. A.S.

Kar Plaza Is Merkezi
Kayisdagl Cad. No. 45 E Blok Kat. 6
Içerenköy 81120
Istanbul
Turkey

Tel: 90.216.469.0600
Fax: 90.216.469.0658
 
There are other experts participating in this thread who are far more qualified than I to diagnose this problem, but....

Let's not overlook the fact that the system worked properly for the past three years and for three days this year. The first question hitit should be asking is "What has changed between yesterday when it worked and today when it doesn't"?

At this stage, I'd be looking for problems external to the program. Cables or module terminal strips can work loose, terminating resistors can fall off or break, but program code tends not to wear out.
 

Similar Topics

Most of my lunch hour today has been spent searching the forum for help with this issue. While I did get some help from the various topics I still...
Replies
12
Views
4,919
I received the following in a Private Message from roomi117: Greetings Naeem, first of all, you should post all of your requests in the...
Replies
22
Views
13,880
hello, we have a piece of equip controlled by an allen bradley plc 5/20. after a recent power outage it has failed to resume normal operation. an...
Replies
26
Views
15,745
I have an old PLC (circa 2007) consisting of Telemecanique/Modicon/Schneider Electric devices. The system has developed errors and unfortunately...
Replies
2
Views
230
Hi I’m after some help , I have a plc program with a baumer verisens vision camera attached I have got the signals working ect but I have an...
Replies
9
Views
958
Back
Top Bottom