AB PLC5/11 1771-OAD outputs not active

[PaulKraemer]

Ok, so I won't worry about the lack of I/O config data in my offline program. I do have entries in the output file for all of my discrete output cards. The Channel 1A setup appears to be correct (remote IO scanner). None of my output cards are currently working - neither the ones on the remote rack nor the ones on the same rack as the PLC. I'm going to order a new battery and have my customer re-download the program. I'll see what happens - the machine already doesn't work so it can't make things worse!

Thanks to all of you for your help. This is my first time here and this forum is great.

 

[kamenges]

This may be a dumb question but, in the I/O configuration, is the little Inh box checked on the line that your chassis is listed on? This would indicate that the rack is inhibited. I'm not sure about this but I believe this would cause the active lights to be off.

It doesn't sound like you've been online witht he plc yet. That may tell you something too. Generally, I'm with everyone else. Replace the battery and reload the program and go from there. That will probably clear up alot.

Keith

 

[Ron Beaufort]

... and don't forget the communications issues ...

... so the customer is going to do the download ...

next question ... will he use the processor's DH+ connection or the DF1 connection to do the download? ...

if it's DF1, be sure that he knows how to set up RSLinx ...

basic idea: when the processor completely loses its memory, then the DF1 port (Channel 0) usually goes back to its default value of 2400 baud ... if the customer's RSLinx was last configured for something a little more racy than that, then there's a good chance that he won't be able to complete the download ...

so ... based on my "best-guess-from-where-I'm-sitting" this is the way this is all going to play out ...

(1) in RSLinx ... do an Auto-configure for the DF1 driver to get RSLinx ready to communicate ... you'll probably find that the processor’s baud rate is now 2400 ...

(2) then download the program ... this will probably change the baud rate to something faster (example: 19,200) ... so after the download, your customer’s programming computer (with RSLinx still set for 2400) will lose communication with the processor ...

(3) then go back to RSLinx and do another Auto-configure for the DF1 driver ... this will be necessary to get RSLinx ready to communicate at the newer faster baud rate ...

but then again ...

maybe your customer will be doing the download through the DH+ (Channel 1A) port ... in that case things will probably go a lot smoother ... the baud rate, etc. for the DH+ port is set by DIP switches on the processor which probably haven't been changed ...

 

[Ron Beaufort]

... and one more thing ...

I just thought of something else ... you don't really need a good battery in place in order to try the "download" fix ... once the program is in place, the processor will retain its memory (and program) without a battery at all - just as long as the line power stays on ...

it works pretty much like the alarm clocks that most of us have at home ... as long as the 120VAC wall receptacle stays on, the clock keeps accurate time ... and it faithfully remembers the alarm setting to get you up in the morning ... but if the 120VAC power fails (or even flickers off), then you'd better have a good 9VDC battery installed in the clock ... if you don't, then the time reverts back to 12:00 ... and the alarm settings are gone too ... so the battery is only there for use during those infrequent occasions when the 120VAC power fails ...

now think of the alarm settings as something like the PLC's ladder logic program and the analogy is complete ...