Ecom when will there be a stanard

[PLCGuy]

I keep reading problems with TCP/IP. When will there be one standard. It seems manufactures are jumping on Allen-Brandley bandwagon as far as using their protocol. Am I using the right word? Everyone states they use TCP/IP, but what language? Why can't manufactures get together and make it the same? Remember the days of Hard drives before the IDE came out? It got so you just plugged your hard drive in and off you went, well sorta. I would love to see that happen to ECOM cards. AD has their way, AB has their way, etc.

[franji1]

An open standard already exists, Modbus/TCP, that works with many of the industry-wide Ethernet-based products.  Our ECOM100 module supports Modbus/TCP as both a Master and a Slave.  Are you saying there should only be Modbus and nothing else?  Or are you wanting another standard with features Mobdus/TCP currently does not support?  or???

[Controls Guy]

I keep reading problems with TCP/IP. When will there be one standard. It seems manufactures are jumping on Allen-Bradley bandwagon as far as using their protocol. Am I using the right word? Everyone states they use TCP/IP, but what language? Why can't manufactures get together and make it the same? Remember the days of Hard drives before the IDE came out? It got so you just plugged your hard drive in and off you went, well sorta. I would love to see that happen to ECOM cards. AD has their way, AB has their way, etc.

Believe me, you really don't want everyone to jump on the Ethernet/IP bandwagon.  Modbus/TCP is far simpler and far more open.  I could easily write a driver for Modbus/TCP, but wouldn't even think of trying to do so for E/IP.  Modbus/TCP is already supported by enough people that it won't get orphaned, and it's just a much better protocol whether you need an open protocol or not.

[PLCGuy]

the problems I have with modbus is the offsets and knowing what addresses work. I hooked up a numatics with a DL250-1, using modbus over the ECOM100, what a nightmare that was. Numatics had to develope a card to get rid of the said problem.  I had to deal with offsets and reversal bits. I want to see something like when using the C-More to a AD PLC using ecom100. You just address them and off you go. This is not so simple when you deal with different brands. All say they use Ethernet tcp/ip but the language is different from manufacture to manufacture.  For example Kuka Robots uses the TCP/IP with AB lanuguage. The two work great together because both are using the same language over TCP/IP. Just like AD has their own propieitary language with their ECOM100. You can not connect to any brand and have it work. Let's get rid of that problem and all use the same language. I want to be able to use AD ECOM100 connected to Joe Blows Equipment and just work just like I do when I use all AD equipment, address them and it all works. franjii1. I don't see the simpler part using modbus TCP. Another example is AD's servo system using the modbus. Wow again, the addressing involved to pass info. And this is simpler? Again I would love to see us get to the point of computers got to with the IDE hard drive system. Just plug and go! No longer do you have to fill in how many heads, sectors, etc. Am I a dreamer?

[BobO]

Sounds great. Won't happen any time soon though.

You actually explained the problem...Modbus IS a standard, and yet the addressing is different for everything. Until and unless every automation device conforms to a fixed standard...not just comm...but functions, features, instruction set, addressing, etc...it will remain virtually impossible to create one master comm and addressing specification that will work for all devices.

The automation market is simply too diverse, solving too many problems...process, scada, machine control, CNC, motion, drives, HMI, etc, etc...and yet far is smaller than the PC world...many small companies selling small volumes of specialized products...to expect universal plug and play.

You are correct in saying that Ethernet/IP is such an attempt...it is. And you should look at the spec sometime....it's 1000's of pages...insanely complex. By contrast, Modbus/TCP can be described in a few pages and implemented in a few days. Now if you are willing to pay a company significant money, you can buy toolkits to minimize the pain...but not eliminate it...and then comes the certification testing, also not free. And in the end, you still end up with many of the same issues that you describe...you just do.

In the new controller we are developing, we are making some significant changes to address the addressing problem (yes, pun intended). The pain you describe will be dramatically decreased. Will that eliminate the pain of connecting Vendor A to Vendor B? Sadly, no. But it will help.

[Controls Guy]

It's kind of odd, PLCGuy, but your posts sound to me as if you're saying  "All this different stuff from all these different vendors should talk together seamlessly, so we should get rid of the more open, public, simpler standard and all go with the proprietary one."  I have no particular feeling for or against proprietary busses, especially if the originators make the specs public so others can build compatible products (that's where serial Modbus came from in the first place), but it would seem like if you want more interoperability, it would be a lot easier from the vendors' side to reach that goal if AB dropped E/IP and did Modbus TCP than the other way around, and you would end up with a simpler better product for the user as well.

[franji1]

What's wonderful about competition, you can have open standards, but they tend to implement the "least common denimoniator", like Modbus/TCP.  No, you cannot write a generic ladder program in "Modbus" and download a program using "Modbus", but you CAN monitor or change all the I/O and just about all internal memory using that protocol.

But we ALSO have protocols that are vendor specific that implement the "greatest superset" of features, like Host's ECOM protocol that CAN program 4 different ADC PLC lines (05/06/205 and 405), configure modules, ports, retentive ranges, and various other PLC specific features.  For example, it can configure a D0-DCM module in slot 3 of an 06 to speak MODBUS/RTU @115200 baud parity!  Try to come up with a "standard" protocol that can do that across ALL PLCs!

Modbus/TCP is very much like IDE.  IDE does not specify a file system, let alone an operating system, nor application specific software.  All it does is let you NOT to worry about getting data into and off of a disk.  No O/S.  No application intelligence.  That's the purpose of the hardward/software that INTERFACES WITH the IDE controller.  Very similar problem and solution that Modbus/TCP solves!

It would be nice if I could tell an IDE drive "bring up my expense report from last march" and it work on Linux, Windows, and/or a MAC, with the data stored on a DVD drive, hard drive, even USB drive, regardless of any specific applications installed.  Microsoft is trying to do this with Web-based services, but I bet it's not realtime  .

[Controls Guy]

Well sure, but that's programming.  I don't see how you're going to ever get away from high performance proprietary protocols for programming.  (Though interestingly the DF1 spec, for example, contains a lot of programming functionality.  Whether it has enough for you to write a complete SLC programming package or not I don't know; I never tried.) But PLCGuy is complaining about data transfer, especially wrt interoperability, an application where I think simple, open and non-vendor-owned is the best solution.

Now I'm the kind of guy who would much rather have a 65 GTO than one of these newfangled crap cars with all sorts of closed-architecture electronics that I can do nothing to alter and which may or may not be acting solely in my interests (you know, the guy who paid for the thing in the first place).  I'm aware that not everyone looks at things that way, so your mileage may vary.

[PLCGuy]

You can tell you guys have experience with this stuff and bring out some very good points. Re -thinking after reading the posts, I like the modbus/TCP but hate the addressing problems. Getting back to the Numatics example. Once they developed the module, it made the communication simpler. No reversal bits, no offset. Now they had to make a module specific to AD equipment. Someone mentioned the little guy and yes this would not probably be cost effective for the little guy to develope. But that is how it is. There will be losers and winners in all of it. Thinking about the problems with Numatics to AD PLC it was also the info supplied. The manufacture needs to get out the address info better. If Greg is reading this, he may remember getting involved with this a while back. Hi Greg! He may shine some light on what went on to get it to work. Now that ethernet is growing, it still seems to me a standard for all manufactures could be made if the choose to use modbus/tcp, but then again what about the feature specific, would it work. Maybe a class would be nice. I enjoy programming and love the challenges. Again thanks for all the view points. I actually read them over several times.

[Greg]

...If Greg is reading this, he may remember getting involved with this a while back. Hi Greg! He may shine some light on what went on to get it to work...

Yiiiii! Oh, yeah, I remember! In fact, I wrote an FAQ regarding the bizarre issue:

http://www.hosteng.com/FAQFiles/ECOM.htm#FAQ0080

But, it was fun figuring it out. Besides, PLCGuy, you were indeed the patient/suffering one! 

[Controls Guy]

A long time ago I learned a trick to unravel this type of issue.  I'll give you a fairly recent example.  The customer specified a SLC-5/05 with an Eaton Panelmate as the MMI.  The buttons and other stuff on the MMI didn't seem to be connecting to the PLC.  So I opened a data file window in RSLogix (what BobO calls a "memory dump" because you can see hundreds of values simultaneously), made the inputs from the MMI, and I could easily see what register changed.  In my case it was changing to the actual value I had entered, but even if the value was wrong due to byte swapping, I still would have been able to see where the number was going.  So I did this for a few more addresses, and pretty quick I was able to reverse engineer the rule to translate between AB addresses and Eaton's idea of AB addressing.  Once you know what register the data is going to, you could resolve the byte swapping in a similar manner.

The first time I came up with this idea it was using Iconics' Genesis with a 405 PLC.  It turned out that Genesis must have thought the registers contained 4 byte data or something, because every time you increased the address by 1 (V-Memory address), it actually wrote the data two registers farther out than the previous address.  So if the programmed address was very far from V0 or whatever the base was, the data was actually getting written hundreds or thousands of registers away from where you were telling it to go!

Now I realize that doesn't apply directly to what you're doing because the Numatic valve bank probably doesn't have a PC interface where you can do a memory dump while the PLC is writing to it, but you could work the same principle by programming the PLC to write a test value gradually working across a range of addresses till it hits, then you know the offset, etc.

[Greg]

That's kinda what PLCGuy did. That's how we figured the bytes were swapped in the I/O. We had to conference in 2 engineers from Numatics to comprehend their manual though.