I've been trying out CodeSys on a Raspberry Pi 4 as "training wheels" as a run-up to an actual project replacing an old Allen-Bradley PLC with a CodeSys PC, and run into something odd.
I've been able to connect a basic Ethernet/IP I/O module (a Turck TBEN 8-input, 8-output) to the CodeSys project, and when the project is running, the online monitor shows the module as gree, and the module's Bus LED is solid green, indicating that the bus is active and the Scanner&Adpater are communicating. But when I set an output in the CodeSys program, while I see it go True in the module I/O Mapping screen, none of the physical outputs on the module ever activate (yes, the output power is live).
I've tried mapping each Output bit of the module to separate program variables as Bools, and I've also tried mapping the Outputs as UINT words -- nothing changes.
The inputs are similar -- if I activate an input (and see its LED on the module light up), I never see any of the mapped inputs on the CodeSys Mapping display go True.
I've also tried a different model Turck module, with identical results. I can confirm my test program is running, as the program is "firing" several GPIO pin LEDs in concert with the EIP outputs.
None of the tutorials I've found mention any "special tricks" to mapping EIP I/O. Is there something I'm missing? Or is there something unique to the Pi that I might be tripping over?
By default, no values are transferred to the %I and from the %Q areas, unless they are used somewhere in the code.
If you really want to see them even though they are not used in the code, you can in the IO mapping tab, change the "Alway Update Variables" to "Enabled 1".
I'll try out the "always update" setting, thanks. But I am using them in code. I have some "blinking LED" code running where I mapped my MainTask local variables to the %Q bits of the Turck module. In the CodeSys EIP Mapping screen, I can see the %Qs changing state. But the actual "physical" outputs on the Turck module (ie, the output indicator LEDs on the module) never light.
The %Is are the same, but in reverse -- I can trigger the hardware inputs and see the LEDs light, but the %Is in the Mapping screen never change state, even though I also have them mapped through to variables in my MainTask. Those mapped variables also never change state.
As a sanity check, I have the same "blink" code also driving other variables that are mapped to GPIO outputs, and the LEDs I've attached to the GPIOs do blink. The EIP and GPIO vars are separate, with no overlap, but they're made and mapped identically -- just to different I/O adpaters.
In the meantime, I've run into a new problem that might be related. After a few days of the symptoms I described in the first post, my Pi suddenly began deactivating eth0 every time the CodeSys project was started. I'm not sure what's happening, but every time I started the CodeSys runtime, within 60sec, eth0 would stop working entirely. And could not be reactivated -- reboots, explicit ifconfig down/up, nothing worked. Eth0 was set to a static IP via /etc/dhcpcd.conf, and those settings were still intact, but when rebooted, eth0 would have a status "waiting for carrier," and show no IP address in ifconfig. I tried multiple cat5 cables, and using a switch instead of a direct connection to my PC -- nada. The only way I found to recover (so far) has been to burn a completely new RasPiOS image from scratch and rebuild the Pi from the ground up. I did this about 20 times trying to figure out the root cause, with no luck. Fortunately, I can SSH and run CodeSys over the WiFi connection.
Thinking that this was caused by my use of the EIP driver, somehow, I rebuilt the Pi from scratch, but created a new CodeSys project that never had the EIP scanner installed (GPIOs only, no other interfaces active), and made that the first (and only) project downloaded to the Pi's latest rebuild. And eth0 still died shortly after starting the CodeSys runtime.
However, if I rebuild the Pi without ever running CodeSys on it, eth0 stays up 24hrs+ in testing so far.
On the off chance that this is a hardware issue, I'm putting a new Pi 4 on order, but this is quite odd. It's even odder that eth0 kept working for days, initially, with the EIP scanner active, then suddenly eth0 started to die. At the time, I was only making executable code changes, and had shelved the EIP issue pending any responses in this thread.
The only other datum is that, back when the EIP was "almost working", the EIP diagnostic screen would show that, every 5-10min, the bus would time out briefly (1-2sec), then autorecover. I was treating that as a lower-priority issue, since it did auto-recover nicely.
Well, no joy so far. I tried re-creating the Pi from the original source image again, but this time blocked it from doing any system updates. Eth0 still dies within 60sec as soon as I start the CodeSys runtime for the first time. I've been unable to find anything online that even remotely matches the issue I'm having here.
Finally got my new Pi, and now I have a completely new problem. 😩 I followed the directions in this tutorial (https://youtu.be/QrV7laAJkDk) (using the EDS file for the Turck TBEN module, instead of "generic EIP Adapter"), but unlike before, I can't get the adapter to connect.
The CodeSys Ethernet Adapter is set to the same IP address as the Pi's eth0, and I'm able to SSH into the Pi on that IP. I've also confirmed that I can ping the IP of the TBEN module from the Pi. But when I go online, the EIP Scanner is yellow and the TBEN module is red. I can't figure out what's wrong -- this should be idiot-proof: Add the Ethernet adapter, add the EIP Scanner below that, and add the EIP Adapter below that, config the IPs, and map some I/O bits.
The Log for the EIP Scanner only reports: "1 Adapter successfully loaded",
and "No local Ethernet/IP Adapter found. Class 1 connections as Target not supported"
The Log for the TBEN module shows:
"All resources released",
"UpdateConfig Connector: 3063118872"
and "0 Adpaters successfully loaded".
I'm guessing the long Connecter numbers are handles. And if I'm parsing these messages correctly, it sounds like the Scanner is okay, but it's not finding the TBEN module for some reason. I know the module is good, as I was able to use it with my old Pi two weeks ago before that Pi's problems with Eth0 cropped up. The module hasn't been touched since. Same EDS file, as well.
Log in to post a comment.