Final followup on this thread, for posterity: I engaged in a long discussion with Turck tech support, and they provided me a newer version of the same module -- same EIP stack, but with updated firmware. And it worked perfectly, all inputs and outputs. So it would appear there is some small, but crucial, issue in the EIP implementations between the older module and CodeSys that "broke" the outputs. As I mentioned above, the old module worked perfectly when attached to a Fanuc robot controller.
So, I've been poking at this in my spare time. It turns out that my Eth0 issues on the Pi were caused by the GPIO settings(!). Long story short, I had no idea there were multiple Device Descriptions for the GPIO in CodeSys. I was using a Pi4, with the "default" GPIO description (A/B), and was playing with GPIOs (just to blink LEDs) alongside my attempts at using Ethernet/IP. It turns out that, using the older GPIO description worked, mostly, but if I ever set GPIO28 or 29 to "Output", eth0 would...
Hm... I have Winpcap installed (as part of WireShark) already. If I lacked some critical component, would CodeSys generate any warnings? B/c so far, I only get "device not found" in the EIP Scanner Log. As a test, I connected the module as an EIP Adapter to a Fanuc robot. This doesn't use an EDS file, just basic settings: Product Code, Manufacturer Code, Major/Minor Revs, and number of Bytes In/Out. It worked fine. So I went back to CodeSys, and tried creating a Generic EIP Adapter under the Scanner,...
It occurs to me that, so far, all my successes with EIP and ProfiNet have been on a licensed runtime -- my failures have been on my desk machine, running the "demo" mode 2hrs at a time. The demo mode does ModBus fine, but is it limited on EIP or PN? I've heard elsewhere that the demo mode can't run PN, but will run EIP, but I haven't found a definitive answer. Does anyone know where there might be an official CodeSys document that details just what the "demo" mode can/can't do? (aside from the 2hr...
The plot thickens... The two "production" ModBus modules I've been trying to connect to are proving to be very stubborn (despite working fine on an RS-Logix PLC) -- my customer is looking into replacing them with EIP modules instead. EIP on this CodeSys PC (Win64, non-RTE) has been working effortlessly (so far) on a big Numatics G3 valve/input module stack. In the meantime, I've been using a Turck TBEN multi-protocol I/O module on my lab bench to experiment with. I've been completely unable to get...
The plot thickens... The two "production" ModBus modules I've been trying to connect to are proving to be very stubborn (despite working fine on an RS-Logix PLC) -- my customer is looking into replacing them with EIP modules instead. EIP on this CodeSys PC (Win64, non-RTE) has been working effortlessly (so far) on a big Numatics G3 valve/input module stack. In the meantime, I've been using a Turck TBEN multi-protocol I/O module on my lab bench to experiment with. I've been completely unable to get...
So, a few updates, for posterity. :P My production Ethernet/IP connection worked instantly, just by importing the EDS file. It was for a complex Numatics G3 valve&I/O setup. So my test-bench problems with the much simpler Turck adapters remains a mystery. My ModBus connection, OTOH... I've had no luck connecting to my two ModBus I/O modules: (https://www.acromag.com/shop/signal-conditioning-network-i-o/ethernet-io-modules/ethernet-digital-i-o/xt1120-16-channel-discrete-ethernet-i-o-modules-with-sourcing-outputs/)...
Addendum: I get exactly the same issue connecting these modules to my Raspberry Pi CodeSys engine, and I've checked that these modules function on a regular Allen-Bradley PLC. So there must b something I'm doing wrong in CodeSys, and doing wrong consistently.