Yes, it's quite common. Note that the library is naturally referenced once in the library manager, however you can add multiple EtherCAT masters and underlying topology in the device tree - each of them has to be bounded to one physical or virtual ethernet adapter by MAC address or device ID.
Yes, it's quite common. Note that the library is naturally referenced once in the library manager, however you can add multiple EtherCAT masters and underlying topology in the device tree - each of them has to be bounded to one physical or virtual ethernet adapter by MAC address or device ID.
Dear all, The issue seems to be fixed with 3.5.SP18, works fine. P.
Now I tested it briefly, but couldn't get it alive - the problem is that the Master instance tries to get an exclusive lock on the ethernet adapter at program startup (independent from xBusStop)... But I tried something else, and seems to work. Maybe this is an option for you: - Configure single master, and multiple slaves - Set all slaves as optional - This requires to assign a station address for each of the slaves (Actually the station address(-es) can identify your configuration) - Define the...
Yeah... Maybe a simple "Your IP address is blocked" message without any explanation would be sufficient, so that we know to turn on VPN... :) (or turn it off) By the way, what's the situation with Automation server, and remote access features? Is it still possible to communicate with devices in the region? However, I hope all this disaster will end soon, and we can return "being international"...
Wow... Interesting topic :) I assume we're talking about Ethercat... As a first guess I'd try to use the xStopBus input of the individual master instances: I wonder if this can work...
Wow... Interesting topic :) I assume we're talking about Ethercat... As a first guess I'd try to use the xStopBus input of the individual master instances: I wonder if this can work...