Why Explicit Messaging for Control of Remote I/O is a No No!
Sorry, just me dragging up this old thread again...
I read your reply the other evening but hadn't time to do my reply justice until this evening.
nwboson said:
Hmmm. Maybe I'm missing something. Are you saying that if I mess up my design but I used the more (ridiculously) expensive Compactlogix, Allen Bradley will stand behind me? Of course not...
Are you asking me, or telling me? Now remember, and as you put it, we are "respectfully" disagreeing here.
Of course they will support you, as a customer. If you "mess up" anywhere while in the design stage, they will happily guide you back on track, no matter what platform you are using, MicroLogix, CompactLogix, etc. What they will not support is a solution which they have expressly stated, for very good reasons, is not designed, intended nor supported, and not for the reasons you seem to think. They will advise you in such a case to use a correct solution for the application in hand.
"Of course they will", you say..."they will want me to use the (rediculously) expensive CompactLogix", you say...
nwboson said:
...I have found most of my customers will opt for the most cost effective approach: it sure helps win bids...if I can get it done less expensive, and just as reliable with cheaper hardware, I win the bid. And the other guy doesn't.
The customer can often be blinded by the price, and may not be educated enough to know the difference between subtleties, such as Explicit messaging and Implicit connections. Expense is a relative term in this game. Is it better to do it more inexpensively or more correctly? Your above statement might suggest you are convincing yourself that it is always ok to use this method of passing I/O data, just to win bids? I know that's like a red rag to a raging bull for you because you say you are doing it "just as reliable". But I'll stress it again. If you are only using Explicit messaging for non time-critical I/O data between controllers, then that is a fully supported and common practice. But if you are using Explicit messaging to "Control" time-critical I/O data, then that is not supported and can actually be dangerous, or at the very least not 100% "Control Reliable".
nwboson said:
...Now, bottom line, if someone were to say explicit messaging between a network of PLCs (be it 1400, 1100, S7-1200, or any other well designed network PLC) is not safe or does not work...(while Controlling Remote I/O)
I think I just did? However, I would not go as far as to say it does not work, more it does not work deterministically.
nwboson said:
...I think of that as fear tactics. Fear is many times a good marketing approach.
There is no fear tactics, propaganda, or conspiracy here. RA will advise you as to which platform suits your application best. If your application requires real-time Control of Remote I/O, they will not recommend the MicroLogix 1400. Not because it means more money for them, but because the MicroLogix family has its limitations. Control of Remote I/O being one of them.
nwboson said:
...However, if you know what you are doing, and you understand the principles of interprocess communication, and you know what a lock is, and you know what a semaphore is, and you understand how to architect an ethernet network then explicit communication is 100% reliable. 100%. 100%.
It is not, or else RA would proudly extol the MicroLogix family as fully supporting "Control of Remote I/O". Good networking architecture has nothing to do with what we are saying here. So you do not need to defend or proclaim your networking prowess. This is an inherent design limitation of this hardware platform. Explicit messaging is inherently non deterministic, synchronous and uncontrolled.
That sounds a bold statement to make?
Why is it non deterministic, synchronous and uncontrolled?
An explicit message is a much slower form of control and non deterministic. This means that you cannot guarantee how long the I/O will take to update when the message is sent, if at all. Therefore all equipment
used in this manner, should be subject to a risk assessment, taking into account the mechanical and electrical implementation. In other words, you need to decide if the I/O data is time-critical or not, as it may cause harm or damage if not updated within a certain timeframe.
The MSG instruction is placed in the program logic, and often queued with other MSG instructions. It forms part of the program scan cycle. The execution of the MSG instruction is synchronous with the scan cycle. It must wait its turn at the end of every scan cycle, or SVC instruction. The MSG instruction has limitations on the ammount of I/O data that can be assigned to the message. To transmit large blocks of I/O may take several MSG instructions. The 1400 has a limited message buffer and queue system. If queued, or not managed correctly, some MSG instructions can be skipped for several scan cycles. This adds overhead to the I/O update time, making it further undeterminable.
Explicit messaging of I/O data is uncontrolled. It is not under the control of a Scanner, whose sole purpose is the aquisition and transfer of the data. Therefore, the I/O data is not real-time data. It is constrained to the delays inherent in the Explicit MSG instruction's execution time, queues, retries, timeouts, errors, etc. If one controller faults, the other will not know until the next cycle of Explicit messages, so monitoring of the connection is only available at the software level.
Implicit connections are deterministic. The connection is managed and maintained by the processor. A watchdog, independant of the program scan cycle, monitors the connection to ensure the data is updated within 100ms after the RPI. If not, a fault is triggered.
They are asynchronous to the program scan. The I/O data is updated at the specified RPI, and is not in any way dependant on the program scan cycle. The Remote I/O Adapter updates the Scanner, which in turn updates the Processor, all within a predetermined time, each time, or else it faults.
Now perhaps you knew all this, but have chosen to either ignore it, or not believe it, but those are the hard facts. Those are the reasons Explicit messaging cannot be 100% trusted with time-critical, real-time, deterministic, asynchronous, and potentially dangerous I/O control.
RA are not in the business of sanctioning potentially dangerous misuse of their products, no more than they are in the business of promoting unecessary hardware usage.
nwboson said:
...Sorry - I jumped back on my soapbox. Its so comfortable up there. I'll get off again...
Well, you did say it was "cheap", you don't want to wear it out too soon, now do you?
G.
