Hi Mike,
Thank you for leaving your feedback! As you have likely read, the purpose of these NI Labs projects are to gather direct feedback which well help determine what kind of features are important to customers, drive future development, and and help determine what direction the technology may go. As such, I really cannot give you any official "statement of direction" because we are constantly evolving based on this feedback. I'm not sure which whitepapers/videos you are describing, but I would not necessarily infer any "direction" from their contents. They are likely trying to explain features/usage as it exists today. Keep in mind that there are many various product lines that this EtherNet/IP technology applies to, all with separate marketing folks, so it is very possible that you might have different product lines using this technology for vastly different purposes.
Regarding the idea that we are concentrating on becoming an adapter/server for AB controllers, I would say this is not quite correct. We are trying to add features on a priority that matches what we see customers wanting. More than 90% of EtherNet/IP requests I have seen involve AB PLCs (and lets face it, Rockwell created the standard and is still the main user of it), and I'd say we are making great progress towards filling that communication gap and solving the use-cases we see customers wanting. In general, when interacting with AB PLCs, the explicit messaging requests as well as the implicit I/O Adapter-class communication is what those customers with AB controllers seem to want. We have not seen very much requests for working as a implicit I/O scanner (the role the PLC generally takes) as really the only use-case is to be able to collect data from industrial I/O modules that are marketed towards the PLC users. In general these modules either are geared towards one specific PLC type such as AB (and make use of AB-specific functionality like Add-On Profiles with RSLogix) or support multiple protocols such as ModBus. Also, keep in mind that EtherNet/IP is not quite a single standard as it sounds on paper. Between explicit and implicit communication, originating versus being the target of communication, vendor-specific objects and service codes encapsulating other protocols, etc, it is a much larger standard to just claim generic "support" like we do for Modbus/TCP. While EDS files exist, given that most vendors don't seem to actually use them as a means for actually integrating them into their software but rather go the route of having custom support for each module, I have some doubts about how useful being able to load an EDS file would be. We'd be interested in hearing more about what kinds of I/O modules you would like to communicate with though and what types of EtherNet/IP communication it supports.
It may also interest you know that we will shortly be adding support for the generic Get/Set Attribute Single service codes. This should make it easier to do explicit messages to many generic devices that are not covered by the Data Table Read/Write and PCCC service codes that our existing explicit messages cover. In fact, you can likely use these to read/write to the assembly objects on your I/O module (though in a polled fashion, not an implicit I/O data connection). However, if you do that in a separate loop you may be served nearly as well depending on your application requirements.
In general, please be sure to continue giving detailed feedback regarding what kinds of support you'd like to see. Without such information, we cannot accurately gauge what features are most needed. Any details such as the actual device you are trying to communicate and application details (such as timing) are very useful. Also, in addition to this forum, be sure to involve your local NI sales rep if you have specific needs that you would like to see met. While of course as an engineer I'd like to be able to support every feature under the sun, projects and features are obviously funded by customer needs and it can't hurt to involve your sales rep if you feel a particular feature is a requirement for your project. While these forums are great for getting communication between end-users and developers, it doesn't provide an accurate mechanism for quantifying how valuable particular features are in a larger context.
I hope this helps answer your questions at least a little,
Eric
