Steve Bailey
Lifetime Supporting Member + Moderator
I'm hoping there's someone here with a long memory. I Also posted this at the GEIP forum.
Customer has a 90-70 with two Genius bus controllers. One of the busses has three Horner OIU187 HMIs. As far as I can tell from the GBC configuration and the files for the OIU187s, they are getting their data from the PLC by datagrams as there doesn't appear to be any global data associated with them. Based on the addresses configured in the setup, two of the OIU187s would need a single datagram to refresh their data and the third would require two datagrams. They are all set up for 4 datagrams per second.
Lately they have begun to occasionally lock up. They will show asterisks instead of data and the function keys won't respond as they are configured to. They can get unblocked by cycling power to them or by removing/replacing the Genius cable. When that is done they start communicating again, but the act of taking them offline and restoring them generates a fatal fault in the PLC and shuts it down.
When I take one of them offline a "Loss of device" fault shows up in the I/O fault table as expected. When I put it back online I get an "Addition of device" in the I/O fault table and at the same I get a "Configuration Mismatch" in the PLC fault table. That's the fatal fault. It points to the rack/slot location of the GBC.
That same bus has Genius blocks, Field I/O drops, two 90-70 racks with a Genius network interface, and two PCIM cards. The bus is loaded, only Genius SBAs 0, 18 and 30 are unused and the bus scan time is 56 mS. I'm going to calculate the expected scan time based on the number of nodes and the amount of data from each and see how that compares to what the Genius handheld reported.
Nothing jumps out at me in either the 90-70 hardware configuration for the GBC or the file for any of the OIU187s, and the system has been in service for several years.
My current working hypothesis is that the issue has been lurking for a long time and the bus integrity or grounding has deteriorated to the point where noise issues are slowing things down. I'm thinking that the datagrams sent by the OIU187s are stacking up in a buffer and that eventually the buffer overflows causing the OIU187 to lock up.
Does anybody have any experience with this combination and can offer suggestions? I talked to Horner tech support this afternoon and when I asked if I could speak to an "old-timer" the guy I was talking to said that he was the "old-timer" having been there for fifteen years and he wasn't able to offer anything beyond what I've already tried.
Customer has a 90-70 with two Genius bus controllers. One of the busses has three Horner OIU187 HMIs. As far as I can tell from the GBC configuration and the files for the OIU187s, they are getting their data from the PLC by datagrams as there doesn't appear to be any global data associated with them. Based on the addresses configured in the setup, two of the OIU187s would need a single datagram to refresh their data and the third would require two datagrams. They are all set up for 4 datagrams per second.
Lately they have begun to occasionally lock up. They will show asterisks instead of data and the function keys won't respond as they are configured to. They can get unblocked by cycling power to them or by removing/replacing the Genius cable. When that is done they start communicating again, but the act of taking them offline and restoring them generates a fatal fault in the PLC and shuts it down.
When I take one of them offline a "Loss of device" fault shows up in the I/O fault table as expected. When I put it back online I get an "Addition of device" in the I/O fault table and at the same I get a "Configuration Mismatch" in the PLC fault table. That's the fatal fault. It points to the rack/slot location of the GBC.
That same bus has Genius blocks, Field I/O drops, two 90-70 racks with a Genius network interface, and two PCIM cards. The bus is loaded, only Genius SBAs 0, 18 and 30 are unused and the bus scan time is 56 mS. I'm going to calculate the expected scan time based on the number of nodes and the amount of data from each and see how that compares to what the Genius handheld reported.
Nothing jumps out at me in either the 90-70 hardware configuration for the GBC or the file for any of the OIU187s, and the system has been in service for several years.
My current working hypothesis is that the issue has been lurking for a long time and the bus integrity or grounding has deteriorated to the point where noise issues are slowing things down. I'm thinking that the datagrams sent by the OIU187s are stacking up in a buffer and that eventually the buffer overflows causing the OIU187 to lock up.
Does anybody have any experience with this combination and can offer suggestions? I talked to Horner tech support this afternoon and when I asked if I could speak to an "old-timer" the guy I was talking to said that he was the "old-timer" having been there for fifteen years and he wasn't able to offer anything beyond what I've already tried.
