https://forge.codesys.com/drv/io-drivers/tickets/You searched for !status:wont-fix && !status:closedenFri, 28 Feb 2025 09:31:07 -0000https://forge.codesys.com/drv/io-drivers/tickets/6/This could be a huge topic, but now quickly some practical questions / wishes: #####1. Coding / debuging with IoDrvBase Most of the IoDrvBase library is hidden using {attribute 'conditionalshow'}, and that's very much reasonable. However, it is uncomfortable in my case, where I don't have the source library, therefore I can't see inherited items while coding, or debugging. Typical invisible items are: -m_info -m_hInterface -m_pConnector -m_wModuleType -m_dwInstance But then there are all those _counter variables, and who knows, what else So I ended up (temporarly) adding my own member variables as pointers to these elements like: ~~~ _wModuleType : REFERENCE TO UINT REF= m_wModuleType; ~~~ Or... ~~~ _pwModuleType : POINTER TO UINT := ADR(m_wModuleType); ~~~ I know, it is can be unsafe, especially with the rederences, but I never use them from the code, only to see these items in the debugger. ***Is there a proper way to do this?*** Maybe could use something like {attribute 'conditionalshow' := 'Library_Developer'} in IpDrvBase? Or? #####2. Counter variables defined and used in IoDrvBase I might be totally wrong, but I have the impression that these variables are not just for debugging, but have importance in the behavior of IO manager as well? Is it something about detecting if a driver implements a specific call, and actually took action? If it is so, would be great to highlight their importance, maybe describe them together with the expected return values of the IoDrv* calls If they have no such importance, might be better to remove them from the template... I'd be more than happy to do these updates, if I receive a short answer, and permission to modify the tickets... Strucc.cFri, 28 Feb 2025 09:31:07 -0000https://forge.codesys.com/drv/io-drivers/tickets/6/https://forge.codesys.com/drv/io-drivers/tickets/5/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 Strucc.cFri, 28 Feb 2025 08:38:01 -0000https://forge.codesys.com/drv/io-drivers/tickets/5/https://forge.codesys.com/drv/io-drivers/tickets/4/https://forge.codesys.com/drv/io-drivers/doc/Generic/#datatypes First example the IEC struct's type name is "DUT" but the type name in the DevDesc is "Channel4Byte" Further the bytes names in the IEC struct are Byte0, Byte1, Byte2, Byte3, but in the DevDesc they are Byte1, Byte2, Byte3, Byte4 Do the names not matter? bnewmanFri, 10 May 2024 18:30:17 -0000https://forge.codesys.com/drv/io-drivers/tickets/4/https://forge.codesys.com/drv/io-drivers/tickets/3/Some of the documentation and some projects show 0004 as the vendor ID. That is actually the vendor ID for CODESYS Configs. The Open source device drivers should be using the vendor ID 0003 for Open Source Tasks: 1. Find references to Vendor ID 0004. 2. Correct these references to Vendor ID 0003. 3. Decide if drivers already using 0004 should be changed to 0003. 4. When yes to 3, work with the community to update the device descriptions.i-campbellSat, 20 Feb 2021 18:52:14 -0000https://forge.codesys.com/drv/io-drivers/tickets/3/https://forge.codesys.com/drv/io-drivers/tickets/2/An SPI or I2C low level howto would be helpful.IngoFri, 08 Feb 2019 07:47:09 -0000https://forge.codesys.com/drv/io-drivers/tickets/2/