I/O Drivers

I was trying to organize the namespace usage and visibility in some of my custom made drivers (messing with the library manager entries, placeholders, etc...), and I payed a high price for it especially the debugging time after, to find out the reason of some unexpected side effects.

**So I thought it would be a good idea to clarify this: **

(1) What standard libraries / placeholders should custom I/O driver library reference
(2) How to include platform or driver specific libraries
(3) What library properties should the custom I/O driver library library set

How to implement proper namespace usage in the IODriver environment, especially because many components of it seems to rely on the usage of root namespace.**

1. Referencing standard libraries for I/O driver implementation

Background: I am using standard CODESYS version 3.5.20.5

Returning to the roots, I made a fresh download of the standard IoDriverFB, and see how it does it behave.
By Default, not so good, not even after setting the placeholders to the recent versions.

After some investigation, I found that none of the referenced libraries export the calls for CmpIoMgr, and actually they are hidden in the CmpIoMgr_implementation namespace, what is reasonable.

So, if I am correct, these should be exported by the IOStandard library, and yes, they were in previous versions. Changing the placeholder back to 3.5.13 seemingly solved this problem... I see many of factory made drivers are referencing this version...

So, how to do this correctly?

2. Using platform- or driver specific libraries inside IODriver

I guess it is common to use some structure or functionality from Ethercat Stack, CAN, Modbus libraries, or other custom made utility libraries. The basic question is if they can interfere with the IO-Driver (naturally yes), and how to avoid that? There can be no general answer for that, but some guidelines could be provided.

• Allow qualified access only - If it is feasible highly adviseable
• Hide in dependency tree - ?
• Usage of placeholders, fixed or latest versions ?
• Optional libraries (for example a device might be relate to EtherCAT and CanOpen conponents, it has the way to find out how to reach and use their mailbox services. It would be nice not the relate on, and not to load Ethercat stack in an application purely using CANOpen...

This to be explained much more...

3. Library properties of the IO Driver

• How much to follow LibDevGuide rules in IO-Driver libraries? I see, it is not common...
• Do these properties influence the behavior of the drivers? Especially I think about:
  LanguageModelAttribute : qualified-access-only / qualified-access-mandatory