1734 Modules

Our EtherNet/IP Scanner is adaptable to lots of different platforms, processors and RTOS environments. It can do both Explicit and I/O messaging and pretty much support an unlimited number of slave devices. We’ve built it to both be easy to integrate and flexible. I think that we’ve done a pretty good job at that.

That software fulfills a need for those customers that for whatever reason won’t or can’t use a Logix PLC in their automation application. ControlLogix and CompactLogix are excellent control platforms but sometimes they just aren’t right for some applications. I don’t often enter into discussions with customers about their platforms but I know that many of them want to tightly integrate databases, decision systems or other analytical software with their control and just can’t do it with a PLC platform.

If they have a university background or hate Microsoft they will use Linux. Linux is one of the most popular platforms for these sorts of supervisory – hard control solutions. Other times they will use one of the Windows platforms (CE is also popular) or an MQX or a QNX. We don’t care. We have adaptations for all the major RTOS platforms.

The problem always comes in when they tell me they really like Point I/O. That’s good because I’m also a fan. If Point I/O had a Facebook page I’d do a Like and be a Friend to it. I hardly understand those terms but I got a bit of insight watching my 10 year old granddaughter updating her FB page yesterday. God knows what’s on that. (Maybe I should find out)

The 1734 Point I/O modules are really nice. I’ve always liked them. Lots of cool features. You can mount them in different ways. You can insert and remove them under power. You can organize them in whatever configuration makes sense. The wiring system is removable. And they support lots of networks; all the ones you’d expect plus Profibus DP.

And they look good too. If GQ ever does a cover on I/O modules the 1734 family might make it.

OK, I can hear you guys saying “Enough Already. What’s the point?”

Ah Yes, the point. The point is that I kind of cringe when I get that question. It’s not that I don’t want to answer it, it’s just that the answer is difficult to easily convey to the questioner.

AB built these modules with a very highly integrated interface to the PLC. As with a lot of AB products they work very well together in a system consisting of all AB products. In a homogeneous system like that a PLC “knows” a lot about those modules. Information that our software just doesn’t know. It makes them easier to integrate into a PLC but makes it more difficult for us to integrate into a Linux EtherNet/IP Scanner application.

Here are some of the issues we have to deal with.

·         The I/O assemblies vary with what specific I/O modules are installed. Gathering the input and output assembly instance numbers and sizes is a real pain. Right now we don’t know a good way to do this other than connect the module to a PLC and reverse engineer that data.

·         Each Point I/O module may have unique configuration data, which if required by the end user, must be sent with the forward open message. This can be hundreds of bytes of cryptic data. Again there isn’t much documentation on the contents of that configuration data.

·         Some point I/O modules support rack optimized I/O while others support both rack optimized and Direct Connect. In rack optimized the Scanner connects to the entire rack as one device. In Direct Connect, it can connect to each module individually. There is usually different configuration for each of these methods
There is a document that covers a lot of this information:
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1734-um016_-en-p.pdf

But even with this document there is a lot of labor involved for our EtherNet/IP Scanner to support these modules. It’s not impossible but certainly not as easy as supporting off-the-shelf I/O for other I/O platforms.