Post by smic on Virtual Control SL Profinet connection
CODESYS Forge
talk
(Post)
Hi. I'm trying to connect Profinet device with Virtual Control for Linux SL. After adding devices, I couldn't find actual device by Scan Device? Do I missed something? VPLC container on Docker IP: 172.17.0.4 Subnet: 255.255.0.0 Gateway: 172.17.0.1 Profinet device: AL1100 io-link master (default setting) IP: 0.0.0.0 Subnet:0.0.0.0 Gateway:0.0.0.0
Last updated: 2025-02-28
wiki Discussion
jensj
wiki
(Discussion)
Forum for wiki comments
Last updated: 2025-02-28
blog Discussion
jensj
blog
(Discussion)
Forum for blog comments
Last updated: 2025-02-28
(no subject)
jensj
wiki
(Thread)
Last updated: 2025-02-28
Post by fabiodasilveira on PLC Shell commands via ST Code
CODESYS Forge
talk
(Post)
Hello Everybody, I have created a project for an Eaton XC303 that sends lots of data to a router via UDP. It works fine. However, when there is more than one product connected to the router, then it is necessary to change the IP address of the Ethernet port 0, from e.g. 192.168.2.11 to 192.168.2.12 (second product). It is easily done via PLC Shell (setipaddr 0 192.168.2.12), but the people in production is struggling with the PLC Shell commands and I would like to create a Visualization page that will hide that. I used the instruction: eChangeIPResult:= SysSockSetIPAddress(strEthernetPort, strIPAddress); and it works, until the PLC resets. I already read some posts and it appears that I need to stop the Ethernet 0 port and Reconfigure it, but I am really struggling to find the right way to do it. Any help will be much appreciated.
Last updated: 2025-02-28
wiki Discussion
hanning
wiki
(Discussion)
Forum for wiki comments
Last updated: 2025-02-28
blog Discussion
hanning
blog
(Discussion)
Forum for blog comments
Last updated: 2025-02-28
Home
jensj
wiki
(WikiPage)
Project Members: jensj (admin)
Last updated: 2025-02-28
Ticket #5: Namespace of I/O Driver related libraries
I/O Drivers
tickets
(Ticket)
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 2025-02-28 08:38:01.989000 Ticket #5: Namespace of I/O Driver related libraries I/O Drivers io-drivers tickets tickets False /drv/io-drivers/tickets/5/ Ticket Namespace of I/O Driver related libraries False 1 2025-02-28 08:38:01.784000 5 Namespace of I/O Driver related libraries open 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 False False 0 0 0 None 1.0 struccc codesys-com
Last updated: 2025-02-28
Post by smic on Virtual Control SL Profinet connection
CODESYS Forge
talk
(Post)
I found the solution. The NIC information on Deploy control SL should be defined to scan profinet devices. So I moved to the next challenge. Device is founded but still it has orange mark not green.
Last updated: 2025-02-28
(no subject)
I/O Drivers
tickets
(Thread)
Last updated: 2025-02-28
(no subject)
hanning
wiki
(Thread)
Last updated: 2025-02-28
Home
hanning
wiki
(WikiPage)
Project Members: hanning (admin)
Last updated: 2025-02-28
Ticket #6: Visibility control in I/O driver libraries
I/O Drivers
tickets
(Ticket)
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... 2025-02-28 09:31:07.844000 Ticket #6: Visibility control in I/O driver libraries I/O Drivers io-drivers tickets tickets False /drv/io-drivers/tickets/6/ Ticket Visibility control in I/O driver libraries False 1 2025-02-28 09:31:07.352000 6 Visibility control in I/O driver libraries open 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... False False 0 0 0 None 1.0 struccc None
Last updated: 2025-02-28
Post by struccc on Multiple applications on one device sharing variables.
CODESYS Forge
talk
(Post)
I don't exactly recall where (I think some release notes), but I read the information that this multiple application / sub application feature is to be discontinued. Please, correct me, if I'm not right about this I am a bit sad about that - I was using that feature with more or less success. However I understand the reason behind the change: it introduces huge complexity, especially when dealing with multicore and safety support... AS I understand, it's to be replaced with the new virtual plc architecture, and standard ways for synchronizing / sharing data... So, for now the "Add application" context menu item was removed, but behind the scene it is still supported... Hint: if you still want to experiment with it, might try copy-paste things within the PLCLogic tree...
Last updated: 2025-02-28
(no subject)
I/O Drivers
tickets
(Thread)
Last updated: 2025-02-28
Post by struccc on When running as a service, CodesysControl doesn't write log files to the disk (and other CmpLog related issuess)
CODESYS Forge
talk
(Post)
Are you sure when running as service, it is not reading configuration from C:\Windows\System32\config\systemprofile\AppData\Roaming\CODESYS... ? Is the SRV user is set for the CODESYS services? 2 ways to fix it: Change the CODESYSControl.cfg in the installation directory (ProgramFiles/CODESYS...). Replace %APPDATA% with something fix. Modify the service configuration in windows service manager to run as a different user (ie bot as Local system account)
Last updated: 2025-02-28
Post by eschwellinger on Virtual Control SL Profinet connection
CODESYS Forge
talk
(Post)
means not licensed demo mode.. use the Licenserver on the host and apply a license and add the Ip of the license server then it will be green.
Last updated: 2025-02-28
Virtual Control SL Profinet connection
CODESYS Forge
talk
(Thread)
Virtual Control SL Profinet connection
Last updated: 2025-02-28
wiki Discussion
kirtiraj5
wiki
(Discussion)
Forum for wiki comments
Last updated: 2025-02-28
blog Discussion
kirtiraj5
blog
(Discussion)
Forum for blog comments
Last updated: 2025-02-28
(no subject)
kirtiraj5
wiki
(Thread)
Last updated: 2025-02-28
Home
kirtiraj5
wiki
(WikiPage)
Project Members: kirtiraj5 (admin)
Last updated: 2025-02-28
Home (version 1) discussion
rringo
wiki
(Thread)
Home (version 1) discussion
Last updated: 2025-02-28
wiki Discussion
maxsuelcunha
wiki
(Discussion)
Forum for wiki comments
Last updated: 2025-02-28