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?
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi @skyefire,
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.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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",
"UpdateConfigConnector 3063118656"
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.
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",
"UpdateConfigConnector 3063118656"
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.
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 be disabled as soon as the project began execution. And changing those GPIOs back to "not used" and re-deploying the project did not fix the problem.
Once CodeSys tech support clued me in to right-click my GPIO description in the Device Tree, select Update Device, and use the B+/Pi2 version, I got several more GPIOs available, and was able to set all the GPIOs to Output without losing Eth0.
On the EIP front, I have the inputs from the Turck modules working (including the diagnostic bits). But I still can't get the outputs to work -- I have them mapped in my CodeSys projcet, and can see the inputs go True when I close a hardware input, but setting one of the outputs in CodeSys doesn't energize any of the hardware outputs on the module.
The oddest thing is that, if I switch to ModBus, the same modules (which support EIP, ProfiNet, and ModBus), the module works 100% -- inputs and outputs.
(on a side note, when I use EIP, the module keeps disconnecting/reconnecting every few seconds, but when I'm using ModBus instead, there are never any dropouts).
I tested the EIP functions of the module by connecting it to a Fanuc robot (using just "generic" settings, no setup tools), and it worked 100%. So I know the module itself is good.
I even tried creating the modules as a "generic EIP device" in CodeSys, doing all the settings from scratch (using the same settings as worked on the robot) -- still no luck.
Just for comparison, I tried creating a CodeSys project that connected to these modules via ProfiNet (using the manufacturer GSD files), but I couldn't even get a connection over the network.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
more posts ...
Hi @skyefire,
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",
"UpdateConfigConnector 3063118656"
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.
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",
"UpdateConfigConnector 3063118656"
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.
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 be disabled as soon as the project began execution. And changing those GPIOs back to "not used" and re-deploying the project did not fix the problem.
Once CodeSys tech support clued me in to right-click my GPIO description in the Device Tree, select Update Device, and use the B+/Pi2 version, I got several more GPIOs available, and was able to set all the GPIOs to Output without losing Eth0.
On the EIP front, I have the inputs from the Turck modules working (including the diagnostic bits). But I still can't get the outputs to work -- I have them mapped in my CodeSys projcet, and can see the inputs go True when I close a hardware input, but setting one of the outputs in CodeSys doesn't energize any of the hardware outputs on the module.
The oddest thing is that, if I switch to ModBus, the same modules (which support EIP, ProfiNet, and ModBus), the module works 100% -- inputs and outputs.
(on a side note, when I use EIP, the module keeps disconnecting/reconnecting every few seconds, but when I'm using ModBus instead, there are never any dropouts).
I tested the EIP functions of the module by connecting it to a Fanuc robot (using just "generic" settings, no setup tools), and it worked 100%. So I know the module itself is good.
I even tried creating the modules as a "generic EIP device" in CodeSys, doing all the settings from scratch (using the same settings as worked on the robot) -- still no luck.
Just for comparison, I tried creating a CodeSys project that connected to these modules via ProfiNet (using the manufacturer GSD files), but I couldn't even get a connection over the network.
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.