AB module 1734-OB8S failing without error

[dbozic]

Hi,

Maybe someone has an idea or has experience something similar. I have few safety IO output modules (1734-OB8S) installed behind the 1734-EP24VDC.
On them I have connected safety signals to few VFD drives (ABB VFD). Everything works perfectly when forcing the outputs and i can see the safety signals turn on in the drive (while drive is inactive). But with one drive it happens that it starts the ID run (first motor identification) and it cannot finish it as somehow the safety output card faults (like the voltage drops and turns off all outputs but reboot without error message-at least I could not find the fault information). Rest of the VFDs are ok, I managed to go through ID run and also start the rotation but this drive is just not going through.
I did try to swap the IO card but the same happens. Running out of ideas, right now I am suspecting at the VFD, but strange thing is that it doesn't faults the module immediately on the run command, but the id run is for at least good 10s until it happens. If the drive would be bad and shorting somehow somewhere I would suspect it would immediately fault the IO module..

 

[robertmee]

If you've replaced the OB8S and the issue remains, and the problem is isolated to one drive as you stated, sounds like either a wiring issue to that drive or the drive itself.

 

[dbozic]

If you've replaced the OB8S and the issue remains, and the problem is isolated to one drive as you stated, sounds like either a wiring issue to that drive or the drive itself.

Yes I agree. The weird thing is the drive worked in factory cabinet test. I will try to isolate the PLC wires out of cable duct to verify there is not some interference. Also will try to reprogram some other outputs to check it isn't that as well.
The weird things is sometimes even some other IO module faults, not the one that has wires to that VFD but some next to it..

 

[robertmee]

Yes I agree. The weird thing is the drive worked in factory cabinet test. I will try to isolate the PLC wires out of cable duct to verify there is not some interference. Also will try to reprogram some other outputs to check it isn't that as well.
The weird things is sometimes even some other IO module faults, not the one that has wires to that VFD but some next to it..

Faults or reboots? And the other ones are before or after the 24VDC Expansion? Sounds like you're getting a momentary brown out on the 24VDC Expansion module. Safety modules are very susceptible and will take time to reboot, whereas a standard IB16 you likely won't even see it reboot, as it will come on line much faster

 

[dbozic]

Faults or reboots? And the other ones are before or after the 24VDC Expansion? Sounds like you're getting a momentary brown out on the 24VDC Expansion module. Safety modules are very susceptible and will take time to reboot, whereas a standard IB16 you likely won't even see it reboot, as it will come on line much faster

All are after 24VDC expansion. Power expansion looks healthy. It doenst look like a full reboot as from PLC software you dont see them offline, they go up very quickly. I analyzed all the videos I have, now I am really suspecting a network issue. It looks to me that NS goes sometimes really quickly (RED-OFF/BACK ON), sometimes in a matter of milliseconds, then the outputs go off and MS starts blinking green. But from the look of it NS goes RED always first. And it goes back online very fast.

 

[robertmee]

All are after 24VDC expansion. Power expansion looks healthy. It doenst look like a full reboot as from PLC software you dont see them offline, they go up very quickly. I analyzed all the videos I have, now I am really suspecting a network issue. It looks to me that NS goes sometimes really quickly (RED-OFF/BACK ON), sometimes in a matter of milliseconds, then the outputs go off and MS starts blinking green. But from the look of it NS goes RED always first. And it goes back online very fast.

That will cause the all modules to drop out and takes time for safety modules to reconnect vs standard modules. You may or may not see it online in the IO tree. I usually GSV the network status of all AENTs and manage with code on failure accordingly. Outputs are configured to turn off, but input modules will hold last state on comm failures which can be a problem.

 

[dbozic]

That will cause the all modules to drop out and takes time for safety modules to reconnect vs standard modules. You may or may not see it online in the IO tree. I usually GSV the network status of all AENTs and manage with code on failure accordingly. Outputs are configured to turn off, but input modules will hold last state on comm failures which can be a problem.

I did the GSV on all the modules, put the parameters Classname=Module, Attribute=FaultInfo & FaultCode but nothing was shown here. As I said the restart is fast, is it possible something was shown and overwritten later on those variables? Maybe I need to trace those two variables in case they overwrite on the next healthy cycle when the module goes back up.
Thanks for your help, much appreciated. I am not very experience with Rockwell.

 

[robertmee]

I did the GSV on all the modules, put the parameters Classname=Module, Attribute=FaultInfo & FaultCode but nothing was shown here. As I said the restart is fast, is it possible something was shown and overwritten later on those variables? Maybe I need to trace those two variables in case they overwrite on the next healthy cycle when the module goes back up.
Thanks for your help, much appreciated. I am not very experience with Rockwell.

The modules aren't faulting, the parent AENT is losing comms. The GSV I was referring to was the comm status of the AENT. Search EntryStatus for examples.

 

[dbozic]

The modules aren't faulting, the parent AENT is losing comms. The GSV I was referring to was the comm status of the AENT. Search EntryStatus for examples.

I did trace that as well. I think here it was also nothing but will check again tomorrow and leave feedback. The AENTR module itself doesn't show any sign of faulting when this happens.

 

[ASF]

Just a heads up that around a year ago, I had several 1734-OB8S modules brand new from authorised Rockwell distributors faulty out of the box, all with a similar manufacturing date. They would run fine for a while then randomly disconnect (and drop out all safety outputs). They would often come back online without intervention. I replaced the terminal base and the OB8S module multiple times with the same results, sure that this must mean the problem was not with the OB8S itself - but eventually, I borrowed some OB8S's from a different panel with a different date code and the problem immediately went away and has not been seen since.

I can't remember the exact date code - it was September, but I'm not sure of the year - and you may not be experiencing the same thing - but just worth a note because very occasionally, the problem is exactly what it appears to be

 

[robertmee]

Just a heads up that around a year ago, I had several 1734-OB8S modules brand new from authorised Rockwell distributors faulty out of the box, all with a similar manufacturing date. They would run fine for a while then randomly disconnect (and drop out all safety outputs). They would often come back online without intervention. I replaced the terminal base and the OB8S module multiple times with the same results, sure that this must mean the problem was not with the OB8S itself - but eventually, I borrowed some OB8S's from a different panel with a different date code and the problem immediately went away and has not been seen since.

I can't remember the exact date code - it was September, but I'm not sure of the year - and you may not be experiencing the same thing - but just worth a note because very occasionally, the problem is exactly what it appears to be

It was 2021.. Had a plant have the same issue but it was IB8S modules, not OB8S.

https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1135177

There was an issue back in 2018 with OB8S but that was temperature related.

https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1086493/loc/en_US#__highlight

 

[ASF]

Yeah, I found those two technotes at the time, but neither quite covered my modules. I just found the emails I sent to the RA distributor; the date codes were September 2022.

It did seem temperature related as the modules would behave for a while if I took a "cold" module from an unpowered chassis, and then progressively get worse over the next hour as the module warmed up. But this happened with the cabinet door wide open, and the ambient temperature was 10°C (50 degrees foghornate in Freedom Units) so nobody can tell me the ambient temperature was just too hot.

 

[robertmee]

Yeah, I found those two technotes at the time, but neither quite covered my modules. I just found the emails I sent to the RA distributor; the date codes were September 2022.

It did seem temperature related as the modules would behave for a while if I took a "cold" module from an unpowered chassis, and then progressively get worse over the next hour as the module warmed up. But this happened with the cabinet door wide open, and the ambient temperature was 10°C (50 degrees foghornate in Freedom Units) so nobody can tell me the ambient temperature was just too hot.

Thanks for the info...will file that along with the others, as most every job I do now has some form of IB8S or OB8S.

 

[dbozic]

Just a feedback, I did the GSV and to the fault code shown is 515. I had to trace it and record as it resets to 0 very fast and card goes back healthy.
In the end i tried changing the ethernet cable and luckily it went through. Right now is working as expected and hopefully this issue will not reappear.

Thanks for your help, both of you!