What might cause an IO module to be falsely detected?

[OrionHE]

I have a program that I've been using for dozens of the same piece of equipment for years. Today, I tried to load it into a Do-more H2-DM1E and 12 hours later was no closer to running it.

I have one local base and 3 ethernet remote bases using EBC100s. IP addresses are good (double, triple, quadruple, quintuple checked), yet the PLC will not go into Run. When looking at the remote base I/O configuration, if I scan the slave IO, it displays things that don't exist in my PLC bases. I've seen it show 8 DI modules in a row, despite there being zero 8-point DI modules in the project.

I burned a whole day chasing this and AD was as excited to learn from this nightmare as I was to be done with it. I wonder if anyone can shed light on how the PLC "thinks" that an IO card exists in a base. I figure the modules themselves must report their data, or maybe it's pulled from a database. But in my case, it seems to be from thin air.

Help would be greatly appreciated.

[franji1]

Are there any other EBCs on the network?  Make sure these other "dozen" system's slaves are not on the same network with duplicate IP Addresses.

Use NetEdit and compare what it sees with Do-more Designer.  I would query multiple times just to see if it is somehow finding other "slaves".

I will assume you are using Do-more's built-in Ethernet I/O capabilities and NOT using an H2-ERM (if not, let us know).  The built-in Ethernet I/O network is stored as part of the Do-more .dmd project.

Did any of the other systems ever utilize some of the same IP addresses for their slaves?  Did any of them have an I/O Configuration different from the identical slave of the other systems, or were they different.  The disk project does store this configuration, so if you happened to re-use the same project file but with different physical I/O, the slave I/O network would need to be reconfigured to match the actual I/O online (vs. the slave I/O configured in the .dmd project file).

[OrionHE]

https://imgur.com/wKJsRSE
https://imgur.com/fPxjQxe
https://imgur.com/JGeVFBq
https://imgur.com/KYgtlAw

edit: imgur embeds don't work, also images too large to attach

I've attached images that hopefully demonstrate the problem.

We are testing this unit on its own network. The only network devices are the 4 PLC racks and a c-more headless HMI. In the attached images, I read that project from the PLC, so I am ruling out any file on my disk. Our "remote rack 2", when scanning the slave IO, finds incorrect IO modules, and it's not even consistent. This morning it shows empty where there should be modules, yesterday it showed the base full of input cards that don't exist in our BOM.

[OrionHE]

I just discovered you can right click a base in Netedit and view the contents. It also reports incorrectly there, displaying a 16 point DI DO, where there is a 32-point DI.

[OrionHE]

I moved the EBC100 from where were seeing the problem to another rack, swapping the EBC from each rack. Now the EBC100 in a new location shows an H2-ECOM module of all things in the first IO slot. It should be a 16-point DI.

[franji1]

The fact that Do-more Designer and NetEdit are seeing the same flakiness is probably in the H2-EBC100(?).  And that it moved when you put it in a different rack (eliminates 205 base issue).

Make sure the firmware is up-to-date in the H2-EBC100.  If it's "old", it won't work with Do-more (like 10 years old - doubt it, but just asking).

Is this occurring on all 3 EBC slaves?  If it's just the one EBC, do you have a different/new H2-EBC100 you can try?

[OrionHE]

We finally got through the issue. We were certain that we had already replaced the EBC and the problem remained. At one point, we had two racks reporting false information. So, it's possible that we had two bad EBC100s. Anyway, replacing the problem EBC100 (again) seems to have solved the issue and we were able to perform our IO checkout.

Some questions remain:

Is it the EBC100 that reads and reports IO modules to NetEdit/Designer? It seems that each module type has a hex code ID and that is perhaps what is read into the EBC and then passed on. I'm trying to understand the architecture as it may help in future troubleshooting.

Can a bad EBC100 report several false IO modules? We saw, multiple times, the remote rack reporting eight 8-point DI. I'm assuming the answer to this one is "yes".

Can a bad EBC100 report false IO modules that spill over to other Remote Bases with good EBC100s? Either we had multiple bum EBC100s, or this spillover can occur. If the spillover is possible...that really made things difficult to troubleshoot.

[franji1]

We finally got through the issue. We were certain that we had already replaced the EBC and the problem remained. At one point, we had two racks reporting false information. So, it's possible that we had two bad EBC100s. Anyway, replacing the problem EBC100 (again) seems to have solved the issue and we were able to perform our IO checkout.

Some questions remain:

Is it the EBC100 that reads and reports IO modules to NetEdit/Designer? It seems that each module type has a hex code ID and that is perhaps what is read into the EBC and then passed on. I'm trying to understand the architecture as it may help in future troubleshooting.

The EBC100 looks at the backplane and reports what it finds over the network to NetEdit and Designer.  So a bad EBC (bad 205 base, or duplicate IP Addressing) can cause wrong module IDs to be reported.

Can a bad EBC100 report several false IO modules? We saw, multiple times, the remote rack reporting eight 8-point DI. I'm assuming the answer to this one is "yes".

Yes, BAD is very broad.  How it fails can be different, even with the same EBC.

Can a bad EBC100 report false IO modules that spill over to other Remote Bases with good EBC100s? Either we had multiple bum EBC100s, or this spillover can occur. If the spillover is possible...that really made things difficult to troubleshoot.

"Spill Over" is broad.  Technically, no,  However, if the I/O Counts are misreported in one BAD slave, that will affect the Auto I/O numbering in subsequent "good" slaves.  The good slaves I/O COUNTs will be correct, but the Auto Numbering in Designer for the X/Y/WX/WY can be off in these GOOD slaves.  Basically, the earlier BAD slave base's I/O Counts will affect the I/O Auto Numbering of subsequent "good" slave bases.