It is not normal to attempt to configure and run A-B I/O modules that have their own module profiles using Generic Ethernet objects, so please post a good reason why you want to do so.
My go-to example (yes, I've been asked enough times
) is the PowerFlex 525. I run these as generic modules and defer parameter configurations to an AOI.
Because its AOP keys the connection to a specific drive type, you must replace a failed drive with the exact hardware. There's not a lot preventing you from running a 3.0 HP motor with a 5.0 HP drive beyond correct motor plate and overload settings, though. If/when supply/inventory shortages happen, re-building projects and taking processes offline when the short-term, non-essential component fails might not be an option. The customer also only needs to worry about configuring the replacement VFD's IP address with with the original.
Or, for example, customers randomly specify a minimum 3.0 horsepower rating across the board on otherwise "OEM standard" projects containing a scattered mix of sub-3.0 HP motors, you're in need of project rebuilds and keeping track of what settings were done where and why.
- Avoiding the ADC Run -> Program -> Run transition is another aspect.
- Another is the ability to just copy-paste a generic item from the tree into other project trees.
As far as generic I/O goes, if the assembly sizes happened to be the same number of bytes across module types, I suppose it could be argued that the module-specific data could be sussed from a generic
I:[container] type in real-time (DINT, REAL, and groups of BOOL could be realized as DWORD by protocol, for example), and then you could just have unordered racks of I/O that you handle by treating as a pool of assignable resources to various "soft" device objects (i.e. PAx stuff) via a "pointer-to-blob". That's a far-cry from most installations ever realized, but I don't necessarily think it's a pie-in-the-sky, either.
I had a conversation with Rockwell at length last week about this regarding the incoming Armor PowerFlex and how helpful that a "flexible-enough" AOP would be for machine-mountable equipment, no less. Of the Q/A exchange, this one is still outstanding, so I suspect these will also be treated generically when we come to use them.
