mondinmr

I have found a very interesting solution using: IoConfigTaskMap IoConfigConnectorMap IoConfigChannelMap The first is the list of IO tasks. The second is the connector for each IO module in the IOMap. The third is the individual input or output on the IOMap. One of the properties of the connector is another pointer to a connector, which corresponds with the connector of the EtherCAT slave. Through this information, it is possible to understand to which EtherCAT slave an IO connectormap corresponds....

Thank you for the response! It's a path I had already considered, however, while it has always worked for me on inputs, it doesn't on outputs, because if I enable the option to update all IOs at every scan, the IO tasks overwrite each other. However, I have found something very interesting which I am posting below.

Thank you for the response! It's a path I had already considered, however, while it has always worked for me on inputs, it doesn't on outputs, because if I enable the option to update all IOs at every scan, the IO tasks overwrite each other. However, I have found something very interesting which I am posting below.

Using SDO, I can read the EtherCAT mappings and offsets from various registers like 0x1c12, 0x1c13, etc. When I obtain registers mapped in the PDOs and various offsets, I could technically access directly to the statusword, controlword, etc., if they are mapped. I have noticed that on IoDrvEthercatLib.ETCSlave_Diag I can find pointers to the input and output buffers. However, although the input buffer can be easily read by referring to what has been obtained from the SDOs, it is not possible to write...

This library would be very useful for IPC communications. Using a UDP socket on localhost is unpredictable, as with slightly loaded machines it does not even guarantee packet delivery locally. Using TCP creates a lot of overhead. Message named pipes would be an excellent solution for Windows RTE. On Linux, since the release of the extension package, there is no issue, as it is sufficient to develop a component. However, although now 90% of our clients understand that Linux runtimes are better in...

In Windows I need create shared memory in PC software and connect from CODESYS. If shm is not GLOBAL doesn't work due different users between runtime and PC software. PC software need admin privileges. Name need "Global\\" before key. Very unsafe!!! If CODESYS create shared I cannot find key PC side. In Linux I can create shared memory as standard user, bind in the runtime docker, use keys without any "Global\\". Much more safe!!! If CODESYS create shared you need play with permissions to use app...

In Windows I need create shared memory in PC software and connect from CODESYS. If shm is not GLOBAL doesn't work due different users between runtime and PC software. PC software need admin privileges. Name need "Global\" before key. Very unsafe!!! In Linux I can create shared memory as standard user, bind in the runtime docker, use keys without any "Global\". Much more safe!!!