Thanks for sending the system dump!
The Ethernet/IP specification doesn’t support multiple Scanners with exclusive connections to the same Adapter. However, if you set up two instances of the AsEthIP function blocks on two different Ethernet interfaces which have two separate subnets, you sort of end up with two different Adapters. It looks like what you’re trying to do has worked in the past, but it is a bit of a niche use case.
The EIPInit function block, when executed successfully, returns a “handle” variable which is then passed to the other function blocks. This is essentially just a memory address where the function blocks will store and share data between themselves. The key is that these handles need to be unique. You want to make sure each set of function blocks is operating entirely within its own memory space.
Looking at your log files, it looks like every time you get an error, the Logger entry is the same - a memory access violation:
Unfortunately, this error is a little generic. It just means that something tried to read from/write to memory it shouldn’t be accessing. This issue usually stems from improperly used memcpys or pointers. However in this case, the Backtrace can be very helpful. If you click on a relevant entry in the Logger and then click on the Backtrace tab, each of the entries shows something like this:
If you have the relevant project open, some of these entries will show green arrows next to them. This means you can double click them and Automation Studio will take you to the line of code which caused the error. Note that multiple lines will be responsible (a program calls a function which uses a variable etc.) so I recommend looking at where each entry takes you. If the memory violation occurred within the AsEthIP library itself, you will not be able to see the code. However, if the problem can be traced back to something within your program it is more correctible.
Like I said, what you’re trying to do is a little unique, but I’m not seeing anything that makes it impossible as long as it’s done correctly. Something you might want to try is putting both programs in the same task class just to see if that makes a difference. I’m curious though, if both Scanners are on the same Rockwell PLC, why use two connections to the same B&R PLC rather than send all of the data using one connection and exchange data between programs internally on both devices?
Regarding reading and understanding the system dump, the system dump is just a tarball which contains system data in xml format as well as Logger and Profiler exports. It’s essentially a snapshot of the System Diagnostics Manager at the time of creation. There is a program on GitHub you can use to open and view the system dump’s data in a more readable format. This program is very helpful, but note that it is not officially provided or supported by B&R. You can also extract the tarball (with a program like 7Zip) to get the Logger and Profiler files, then open those in Automation Studio.