EIP Concepts/Implementation in BRX

[RBPLC]

See below link for reference. Within the BRX, I assumed EIP explicit messaging was class 3 (not that I know much about EIP). According to the admin, the BRX uses unconnected messaging which is not class 3. Why do you guys use unconnected vs connected messaging? I'm just trying to educate myself more on EIP because as far as I can tell, it's all witchcraft.   


https://community.automationdirect.com/s/question/0D53u00004ujOJsCAM/brx-plc-communication-with-omron-i4l-and-ace-software

[BobO]

We don't use a canned stack in BRX. All of our EIP code is coded in house, so we've tended to rely on ADC's EIP experts to guide us to do the things that give us the best bang for the development buck. Given that EIP is a nest of vipers anyway, every time we do something there it is Very Hard. I couldn't begin to tell you the difference between connected and unconnected explicit. It might even be simple, occasionally it is, but the biggest issue is finding the information to reduce the problem to something actionable. I've done a lot of development over my 30+ year career, and EIP is at the top of the confusion list.

Improvements in EIP are still a priority, and the top of the list is implicit scanner. Had the pandemic induced chip shortages not left us scrambling to keep things in production, it would be done. But stuff. Well, amen.

[RBPLC]

Given that EIP is a nest of vipers anyway

I've done a lot of development over my 30+ year career, and EIP is at the top of the confusion list.

No worries. Just trying to better understand. I keep saying that short of manufacturers providing EDS files that Rockwell users can import, there are very few people who could setup EIP manually. As confusing to you as a developer, I think it's just as confusing to the end users. I understand that it's a pain to deal with/code/implement but it's something that you guys are going to have to do (implicit scanner) to get more people to use DmD platform. Hopefully you guys will get it implemented relatively soon.

Also, is the Modbus "Profiler" going to be in the new release? You had teased it some time back with a potential repository for profiles. If this is established, distributed through AD, and relatively easy to implement within the controller, this might suffice for a great many users who don't want to manually setup components every time. 

[BobO]

Also, is the Modbus "Profiler" going to be in the new release? You had teased it some time back with a potential repository for profiles. If this is established, distributed through AD, and relatively easy to implement within the controller, this might suffice for a great many users who don't want to manually setup components every time.

Yes. The Modbus Scanner is in this release and works nicely. We have a bit more work on some of the product profiles to really gain the most benefit, but we'll get it over time. The basic recurrent scan definition and associated UDTs are there, but in some cases the registers aren't defined. Drives, for instance, can have 100s of registers that can be accessed. The scanner can easily do it without the profile explicitly calling them out, but you might still have to consult a manual.

But to answer the ease of use question, I can attach a drive and have it running in seconds. And in cases where the drive registers are fully complete in the profile, you can read/write them all without ever cracking a manual. Maybe EIP can do the same thing, but even with EDS files, it's usually more painful than that.

[Controls Guy]

I've done a lot of development over my 30+ year career, and EIP is at the top of the confusion list.

You said it, brother!