There are some information missing for me to make a proper decision, so I'll assume the following: You want to use the NexeedAxis object to control the axes and the whole object should provide a single interface for your object users so that they can integrate it nicely into their stations. Reuse is a concern, or else why create an object for it... With these requirements I would create a single command handler object with 2 NexeedAxis objects as internal elements. The common control and status signals and all logic and sequences related to them I'd try to put into the handler itself, but if that proves impractical because there's just too much to do there, maybe create a separate object for it (which has visibility "hidden", because it can't be used without the handler). Then I would create 1 or maybe 2 separate peripherals for the EL6695 which provide "IMyDeviceChannel1" and "IMyDeviceChannel2" so that linking the terminals with my object is easy. All the internal signal allocation from the terminals to the axes and the general stuff is done object-/peripheral internally. This also requires a base object for the interfaces. Not sure if NexeedAxis can be used as an internal element like that or its parameter requirements somehow make this impossible/impractical, but it'd probably work. With this solution, users of my object would only need to drag 1 object instance into their model tree to get the whole thing. Linking to IO requires only 2 parameters in total. When scanning the peripherals from the PLC, the correct peripheral type for the terminals has to be selected though, but a single page of documentation in your object can cover this entirely.
... View more
