PLC5/40 Backplane Problem?????

Join Date
Apr 2002
Location
Burlington, Ontario
Posts
186
Hi guys!

I need your expert opinions on a problem of mine. Here's the story:

We have a solution tank in with we control the level. The level transmitter is analog, and is wired up in to the local rack. Lately, I seen a lot of shift calls stating that the HMI screen "freezes" up.

What has been happening is instrumentation has just been powering down and powering up the plc. The level now is unfrozen, and represent the true level in the tank.

I raised a stink about thier practices on resolving the problem, but wasnever around until yesterday to see what is really happening.

So, yesterday, the level froze again. I got instrumentation to check their instrument, it was reading 25% level in the tank. the PLc was reading 62% tank level. The analog output out of the level transmitter was approx. 8mA, so the istrument was OK.

What I did find though was the block transfer instruction for this analog card was not excecuting. I could write to the analog point for the level and it would accept my edit. i didnt see the ERR bit come on though...strange.

Now, we did power down the plc, and reseated the card. The problem went away, obviously, because the block transfer was reinitalized when the plc was re-powered up. Now I understand why instrumentation thought resetting the PLC "fixed" the problem.

I talking to the ex-line specialist, he indicated that they have had this problem since the plc went in(approx. 6-7 yrs ago.). They have also had problem with sensors in another tank, which just happen to input to the slot next the one that faulted yesterday. They had swapped out the susspected faulty card with another known good one in the rack already, and the problem still/has occured. I suspect the Rack/backplane to be fualty, and think it should be replaced. That is the one thing they haven't tried yet. Now, I should also state that the PLC itself does not freeze, it is still running when this problem occurs. What do u think???


Any input would be sppriciated.

Andrew Evenson :cool:
 
A couple of things to check:

1) The BTR data file has diagnostic info as well as the channel data.
What is the status of the first bit of the first data Word?

Per IFE manual "Bit 00 - Power up bit is used by the module to tell the processor that it is alive but not yet configured. It is a key element in the application program."

If this bit come on, you need to redo the BTW to send the configuration info. This is part of the code that RSLogix autogenerates in its I/O Configuration, but older programs/programmers may not have included it.

2) When the fault occurs, what are the values in S:7 and S:32? These are viewed on the Rack tab of Processor status. If the queue is full (high bits) or the rack is faulted (low bits), then that may be your problem.

For that matter, I once had a "dead" set I/O modules, where the problem was that the rack's Inhibit bit was set. I never figured out how it got set, and it never happened again (one of those "the other shift must have done something" problems), but as long as you're on that screen, keep your eyes open.

3) There's also S:17/0 - "Queue full between local and Remote I/O" (Channel Warn tab), which may mean that you are doing too many BTR/BTWs and choking the system. I've never seen it, but you never know....

That should get you started.....
 
I suspect the Rack/backplane to be fualty, and think it should be replaced. That is the one thing they haven't tried yet. Now, I should also state that the PLC itself does not freeze, it is still running when this problem occurs. What do u think???

I have found that unless you can say "the (part) needs replaced because (specific reason)", then there is usually something else wrong.

I have seen time and time again, hours wasted swapping parts because they "must be bad". In an instance like yours, you have time to do a little research because it doesnt sound like it happens all the time, and it is somewhat easily recoverable.

I would monitor the things Allen suggested, and if you still don't find anything, and still want to swap the rack, try and prove that the rack is the problem.
 
I am going to throw this in whether it applies or not. Years ago with a PLC 5/40 we had mounted in a cabinet on the side of a pallet elevator had a problem with the lock down that held the cards, the vibration would unseat the cards. Is it possible that vibration is involved? The vibration doesnt have to be great, just make sure the hold down isnt left unlatched or is able to vibrate loose.
 
Ron was that problem with the older chassis style or with the newer one (with the retaining bar across all modules)?

I could see that potentially happening on the older design but the newer one seems much more solid.

OG
 
I am just curious if you have any Contact Output Modules (1771-OW16) in this rack. We had a problem a few years ago, not with analog input module, but with an 120 AC input module. The inputs on a card about 2 slots away were going on even thought there was not power to them. The problem turned out to be a bad 1771-OW16 module. Before changing this card we changed the rack which did not help.
 
I had similar problems with a VIM module in an old 5/15 system. The module was losing it's configuration. I simply did a BTW every 10 minutes--whether it needed it, or not. This hurt nothing, took very little processing time, and ensured a good configuration. If the processor isn't reading the analog value, it probably won't see the bit 00 (powerup) bit either, so examining that usually does no good. The key is to "force" a reconfiguration of the card every so often to make it work.
 
Thanks All..

Hi all

Thanks to everyone who relyied. I'l look into all your suggestion!!

This sounds bad, but I hope this problem occurs again, so I can take a look at someof the condition you all have suggested to look at.

Thanks,

Andrew Evenson
 
OG sorry bout the slow response, I am busier than a one legged man in a tail kicking contest.

That unit had the bar but there was some issue with it that didnt "hold" or lock the cards in good "enough". Vibration would allow the cards to "loosen". This was a terrible problem for us at the time, things would stop working and we didnt know why. Reseat or sometimes just a reboot would start everything back....THEN one lucky day something made me notice the looseness in the cards/rack with the bar locked down. THis took months to figure out with alot of call ins when it stopped.

We relocated the PLC into another cabinet mounted on the wall instead of the machine.

Like I said I didnt know if this applied but thought it may be something people would be interested in.
 
Got Some Information...

Hi everyone,

Just thought I'd post some of my trouble shooting results..

Allen:

I checked some of your questions out when the fault happened(today):

1) The BTR data file has diagnostic info as well as the channel data.
What is the status of the first bit of the first data Word?

The First Bit of the First Data Word was False.

2) When the fault occurs, what are the values in S:7 and S:32? These are viewed on the Rack tab of Processor status. If the queue is full (high bits) or the rack is faulted (low bits), then that may be your problem.

- S:7 and S:32 were both equal to Zero
3) There's also S:17/0 - "Queue full between local and Remote I/O" (Channel Warn tab), which may mean that you are doing too many BTR/BTWs and choking the system. I've never seen it, but you never know....

- S:17/0 was NOT set.


I didn't find any faults in the Processor Status File.

rsdoran:

I checked the "locking Bar", it was nice and tight. No cards seemed loose.

Kim Gold:

We actually have an AC ouptut Card (don't know the Cat. number), in the second slot, the analog cards are populated after this card. We havne tnoticed any trouble with the module up to this point.

john paley:

I tried re-downloading the configuration to the card. It didnt do anything.


So guys and gals, I'm stuck. I didnt see any faults indicated in the Processor Status file, re-downloading the modules configuration didnt seem to work either. The only thing that seems to work is cycling the power to the processor.

Thansk for all your help and idea's, if you have any more, I'd certainly welcome them!!

Thanks,

Andrew Evenson. banghead
 
I'm not yet ready to declare that it's the backplane.

First off, what kind of analog input module is it?

If it's an IFE, what was the status of the RUN and FLT lights when the error occurs?

In you first post, you said, "What I did find though was the block transfer instruction for this analog card was not excecuting". How did you determine this?

Did you write a number into the Data file register (say 2048), and not see it get overwritten by "good" data?

If you go to the Data table for the BT control address (are you using BT or N?), what are the status of all the other bits (EW, NR, etc)?

BTR Data Word 0, bit 0 was OFF. Were all Word 0 bits off?

Is your I/O configuration set up so that you can click on the words "Setup Screen" in the BTR/BTW blocks and get the popup?

Next time you get the fault, SaveAs the program. That way, you'll have the data table "frozen in time", and can answer all the questions without having to wait for another fault to answer questions that I should have been smart enough to ask ahead of time.
 
I've seen similar symptoms with IFE's on a couple of PLC-3 systems. I could never determine the where or the why. One other thing that showed in my case was a '1' in an undocumented status bit that I couldn't get any info on (can't remember which one).

What I ended up doing was a kind of sledge-hammer tactic where if I didn't see a BTR done bit for a certain time then I cleared the command word in the control file. This would kick start the BTR again. I haven't seen the problem on a PLC5 so can't say whether the tactic would work there.

I'm inclined to think that the root of the problem is in firmware revisions.
 
More info...

Allen

To answer some more of your questions:

The module is of the IFE series. I dont recall at this time what the rest of the part number was..ill take a look at the prints and let you know. As or your question about the status lights, I don't recall. I'll have to take a better look next time.


I did determine weatcher the Block transfer was NOT functioning because I did write a value into the Data table file, and it was not overwritten by the block transfer. The EN and DN status on the block transfer were NOT "toggling" back and forth either.

As for the control word, were using BT elements. I have not checked the status of this word. I'm still in the learning phase with the block transfer instruction. I've programmed with it before, but have never had to troubleshoot them before, so I dont know all the status bits. BUT I'm learning mre and more every day.

YES, the BTR Data Word 0, bit 0 was OFF. All of Word 0 were bits off

Allen, thats all I have for now, I'll keep looking into the problem.



Gerry

I'll try your approach, in resetting the Control Word. It's worth a try :)

Thanks all for your help.

Andrew Evenson :p
 
While we wait for the next failure:

How is the BTR block called: Is in a JSR/LAD2 that is caled every scan, or in an STI?

What are the conditions for executing the BTR (I would assume just an XIO of the BTxx:yy.EN bit, but you never know)

Is the block set for Continuous?

While everyihing is OK, go online and monitor the BTxx:yy data table, watching how the .EN, .DN .ST (start), and .EW (enable-waiting) bits interplay.

Wait! banghead - Is it just the level sensor channel that freezes, or do all the channels on that card freeze? If the former, then you've probably got bad hardware (Wiring Arm/Card/Backplane). If the later, then it's more likely software (program/firmware)
 

Similar Topics

I am using the following formula and I am getting error, Invalid Expression - too many closing parenthesis. when i copy the formula to notepad or...
Replies
4
Views
132
Preface: Kinda long, so I made section titles Intro: I just want to see if anyone here has seen anything similar. A PLC5-40 series C enhanced...
Replies
3
Views
339
Hi, can anyone help me get a pdf file for this RSP files. They are from a PLC5. Thanks
Replies
1
Views
368
Hello all, I am seeing this behaviour where an integer file (N46:33), has an integer in binary (11110) which is 30 in decimal. I did a...
Replies
7
Views
502
Back
Top Bottom