1734 ACNR - PointBus Status Fault

[QasimFSH]

Hi All,

We are receiving the PointBus Status Fault (led is flashing red), whereas all the other status leds are solid green. Just to eliminate, we have tried changing the module as well but still no luck. All the IO modules connected to this adapter are seemingly fine as well. What do you guys think is the issue? can it be related to power too? Because every time we reboot it, the alarm goes away for some hours.

Please help.

 

[DarrylR]

You could check the chassis size in your logix program configuration. Needs to match the physical setup.

Also looks like the "Network Status" LED is not lit on a few I/O cards. That doesn't seem correct.

 

[QasimFSH]

You could check the chassis size in your logix program configuration. Needs to match the physical setup.

Also looks like the "Network Status" LED is not lit on a few I/O cards. That doesn't seem correct.

Its the quality of the picture, all status lights are correct. We changed the power terminal to the ACNR module yesterday, and an input card as well which once showed an error. Also, reseated all the input and output cards. The physical setup does match with the configuration as well. 13 is the size.

This is really an intermittent issue. it keeps coming after about 20 hours. a physical or remote reset fixes it temporarily.

Any help pls?

 

[QasimFSH]

here is a picture. Can it be a fault related to power maybe?

 

[ASF]

After you reboot it, is it communicating with the PLC successfully until the fault recurs?


Edit: and when you say you tried changing the module, you mean the 1734-ACNR module, correct?

 

[QasimFSH]

All IOs cant go faulty at the same time surely

 

[QasimFSH]

After you reboot it, is it communicating with the PLC successfully until the fault recurs?

Correct. after reboot, everything seems to work fine until it appears again after 20 or so hours.

 

[QasimFSH]

After you reboot it, is it communicating with the PLC successfully until the fault recurs?


Edit: and when you say you tried changing the module, you mean the 1734-ACNR module, correct?

Yes. Have replaced the 1734 ACNR module as well.

 

[QasimFSH]

After you reboot it, is it communicating with the PLC successfully until the fault recurs?


Edit: and when you say you tried changing the module, you mean the 1734-ACNR module, correct?

But also, we have changed one of the input cards (1734 IB8)

 

[ASF]

OK, so the manual gives you some insight into the problem.

Recoverable fault has occurred:

• at power up the number of expected modules does not
  equal the number of modules present >> not the problem. If your chassis size setting was wrong, it wouldn't work at all.
• a module is missing >> it's possible you have a bad module
• node fault (I/O connection timeout) >> Possible
• after power-up of I/O modules is taking place >> it's possible you're seeing unexpected power cycles, but you would expect it to come good after power is restored
• collecting identities >> as above
• verifying configuration >> as above

If the Module Status indicator is solid green, there would appear to be no problem with the ControlNet network side - the problem is entirely on the PointBus side. I did wonder if perhaps you were running short on bus power - the 1734-ACNR can provide 1000mA of bus power, and each of the cards in your photo use up to 75mA each. That puts it at 900mA - so you're pretty close to the limit, but it *should* be fine. Nevertheless, part of my troubleshooting might entail inserting a 1734-EP24DC about halfway along the rack as a trial, to see if it changes anything.

The most likely scenario is a faulty module or faulty base. If you have a terminal base in e.g. slot 5 that's intermittently failing and not passing signals across, then your ACNR will all of a sudden only see 5 modules instead of the configured 12, and then you would absolutely get a "configured number of modules doesn't match observed number of modules" fault. All the modules in the tree will have the triangle because as soon as you get that fault, it drops the connection to the whole rack, but that doesn't mean they're all faulty. Just that the ACNR can't connect to any of them, because the bus size isn't correlating.

 

[QasimFSH]

OK, so the manual gives you some insight into the problem.

Recoverable fault has occurred:

• at power up the number of expected modules does not
  equal the number of modules present >> not the problem. If your chassis size setting was wrong, it wouldn't work at all.
• a module is missing >> it's possible you have a bad module
• node fault (I/O connection timeout) >> Possible
• after power-up of I/O modules is taking place >> it's possible you're seeing unexpected power cycles, but you would expect it to come good after power is restored
• collecting identities >> as above
• verifying configuration >> as above

If the Module Status indicator is solid green, there would appear to be no problem with the ControlNet network side - the problem is entirely on the PointBus side. I did wonder if perhaps you were running short on bus power - the 1734-ACNR can provide 1000mA of bus power, and each of the cards in your photo use up to 75mA each. That puts it at 900mA - so you're pretty close to the limit, but it *should* be fine. Nevertheless, part of my troubleshooting might entail inserting a 1734-EP24DC about halfway along the rack as a trial, to see if it changes anything.

The most likely scenario is a faulty module or faulty base. If you have a terminal base in e.g. slot 5 that's intermittently failing and not passing signals across, then your ACNR will all of a sudden only see 5 modules instead of the configured 12, and then you would absolutely get a "configured number of modules doesn't match observed number of modules" fault. All the modules in the tree will have the triangle because as soon as you get that fault, it drops the connection to the whole rack, but that doesn't mean they're all faulty. Just that the ACNR can't connect to any of them, because the bus size isn't correlating.

Thanks for the detailed answer. I am struggling to figure out which module or its base is faulty. You reckon it can be a good idea to take each of them out one by one, and then see how it affects the system? a power reset will simply fix the issue for sometime without letting us know what the issue is

 

[ASF]

Lots of ways to approach troubleshooting this, and it depends on a lot of factors.

If the downtime caused by the failure is expensive, my first move would be to replace every single terminal base and monitor. The terminal bases aren't that expensive. You could look at placing the removed bases into a test rack to see if any of the symptoms recur, giving you the ability to diagnose further without causing more downtime.

If the downtime caused by the failure is really expensive, maybe you replace every single terminal base and module. More expensive, of course, but the rack going offline half a dozen times costs $X, and if X is greater than the cost of all the modules, it might be worth it. Again, you could look at placing the removed bases and modules into a test rack to try and pinpoint where the actual fault lies.

If the downtime isn't so expensive, you could try replacing one terminal base each time it happens, and see if the problem eventually goes away. If it does, you could look at putting the old modules (except the faulty one) back into their spaces to see if they were actually still fine. As it takes ~20 hours for the fault to reoccur, this would be a very time consuming process - but if the cost of the downtime is low, and the cost of swapping things in and out frequently is low (e.g. if you're onsite anyway and not having to drive an hour to site each time), then that style of approach might get you the most cost effective repair with regard to the cost of the parts you're swapping around.

Two other things you could try:
1. Fully disassemble the rack, inspect closely for bent or corroded pins or signs of mechanical damage. Clean all the pins up with contact cleaner and a soft brush if necessary. Re-assemble and monitor. Basically the grown-up equivalent of me blowing into my GoldenEye Nintendo 64 cartridge and reinserting it as a kid
2. When the fault occurs, browse the controlnet network with FTLinx or similar, and see if the ACNR gives you any indication of what it can "see". Delete and re-create the driver before you browse, because you don't want it showing cards it knew were there at some point but doesn't necessarily see now