ECOM100 lockout problem

[rswolff]

ok....its only right that I post this......i've been ranting about the D0-ECOM100's for about 1-1/2 years now...seemed to work fine until I put together a network with ten(10) of them....then the problems started....main problem was getting the ECOM to fault or disconnect from the plc....with the only workaround being cycling power...now I wasn't passing a lot of information....six of the CPU's read 2bytes from the other five....the remaining four units read 128 bytes from each of the six. There are also three Cmores (one each at a unit in the outer group of four) and one Wonderware station at the remaining unit of the four. I had changed timing, polling sequence, checked connections, etc. and nothing resolved the issue. Today I was able to change the communication to a different strategy....one of the four now polls the six of their 2bytes, and distributes the information back to the other CPU's in the group. This significantly dropped the number of communication packets (it also makes the network susceptible to a single  point failure which was the reason I had the original setup)....presto chango!!! no more lockups at the ECOM's during program edits...regardless of the timeout setting....my guess is some form of a stack issue....I had attempted in the previous setup to stop the communications for a single CPU (from the group of six) and make an edit but still had the lockout issue. So pretty much there are simply less processors attempting to read from the unit being programmed. So everything appears to be working without a glitch..... bob

[Controls Guy]

it also makes the network susceptible to a single  point failure which was the reason I had the original setup

That's why in my other post I suggested including standby masters for redundancy.  I don't believe there's any flag or internal status bit a CPU can look at to tell whether it's been written to or not, but what you could do is add a watchdog register to your read/write packets that the master changes like once every second or something, or that the slave keeps trying to clear and the master keeps trying to set.  That way the slave can supervise the operation of the master and take over if needed.

The backup should also employ some form of watchdogging so that the original master knows not to come back online or some other form of arbitration that you could devise.

[ATU]

Whenever I do multi-CPU coms and its a critical data exchange, I always do a readback check. The receiving unit copies the data where the transmitting unit can read back the transmission from a different memory location and compare it with what it sent. If there was no match, then flag an error or try a retransmission. Its a little more work, but it solved a lot of headaches for partial or missing data. It also detects a slave CPU out to lunch.

[rswolff]

maybe I missed something......my problem had never been verification of the data (so what the heck question are you guys answering?)....problem was the ECOM no longer communicating to the cpu.....I could have had a dozen masters and it wouldn't have made a difference.....and I had timeouts and handshaking.....so every node did know it was no longer communicating to any other node....what freakin (for lack of a better word) did that make? even making simple edits took forever since any time I wrote an edit the update was completed, but the ECOM would disconnect and I needed to recycle power....the CPU's were across three buildings....so cycling power was a real pain in the ass.......bob

[franji1]

I think they are trying to help with the "single point of failure" issue related to changing the network traffic from a peer-to-peer, to more of a centric data concentrator/distributor using one master and multiple slaves.  One of the advantages of peer-to-peer is that if one node goes down, it only affects that node and possibly the ones it is interfacing with (this number may be relatively small, or may not be critical for that one node).  However, with a single data concentrator/distributor, if that one master went down, you know that NO communications between nodes is going on.

So their suggestions first detail how to detect the master is down from each "slave" node (and hence how to possibly handle it).  Then, subsequently how to correct the situation where the master is down by allowing one of the slaves to become the "new master".  Then finally, how the original master, once it is back up, can re-gain the role of master from the secondary master.

Your system may not require this level of "hot backup at a network level", but they were addressing the differences going from peer-to-peer to master-slave work-around, and looking at the "possible anomalies" that can occur.

It was a big jump, so I understand the confusion.  This may not even be an issue in your specific situation.

[Controls Guy]

Whenever I do multi-CPU coms and its a critical data exchange, I always do a readback check. The receiving unit copies the data where the transmitting unit can read back the transmission from a different memory location and compare it with what it sent. If there was no match, then flag an error or try a retransmission. Its a little more work, but it solved a lot of headaches for partial or missing data. It also detects a slave CPU out to lunch.

I do the same thing on buffering protocol bridges (ones that you have to set up in advance with a list of the registers you might poll, then they asynchronously read/write to those registers from an internal area, then respond directly to queries from the master using data already in the buffer).

So then on the buffering ones, if I have control of the slave on the other end of the request, I echo the data to another location, so the master can read that data and be sure it's not getting old data from the bridge's buffer.  With bridges that just translate each query on a one-to-one basis without an internal buffer I've never bothered.

[rswolff]

anomalies withstanding....my network was PEER to PEER precisely because of the issues with a Master/Slave setup. Funny thing though....as soon as I changed to a Master/Slave the faults disappeared.....it did reduce the number of packets, but it did not significantly reduce the amount of data. Even when I had previously stopped the polling from a single node, and attempted to make edits to that node, the problem persisted. Once I only had a single polling CPU the problem was eliminated. This indicates to me some sort of a stack error, as everything else is relatively the same. And my question still stands....if someone asks which hamburger tastes best, answering that you can make sushi from salmon is not really an answer.....even indicating that the meat needs to be cooked properly or else you'll get sick is also not an answer to the question put forward. If I was asking HOW TO PASS DATA, or which is the best method, then their answers might have some validity.