I have an e!Cockpit program that is controlling linear actuators from Thomson. I got the EDS files into e!Cockpit just fine and I can control the devices and read their state, so communications are good. However, I’ve run into an issue where after 5 seconds, the linear actuators fall back to sleep because they are expecting the master (in this case a 750-8216) to keep sending commands or else they will fall asleep after that 5 seconds. Speaking with Thomson, they say ideally the master should be talking to the actuators every 100ms.
My issue is I’m having trouble finding that setting in the CANopen interface settings for the controller. I’ve tried playing with the Sync, the Time, and the Guarding to no prevail. Anyone got an clue how to keep the controller talking to the slave devices more often or even continuously when it sends a command?
Current behavior is that the actuator runs for 5 seconds, falls back to sleep, and then 4ish minutes later the controller must send the message again because the actuator will then run for another 5 seconds and then repeat this behavior until it reaches its commanded position.
Hello Kurt,
I tried those settings (for Kevin) and it did not seem to work. I will note that the NMT start all and NMT error behavior are greyed out in our program and cannot be changed. I will also note that the Sync Cycle period needs to be a minimum of 5000 us (per the error message e!Cockpit gave me when trying to login and download the program). The linear actuators are still acting like they only get one command and then timeout (go to sleep) after 5 seconds.
I have seen this behavior on a different CANopen Slave device. Like you I activated the SYNC protocol but it did not solve the issue alone. In the end I had to change transmission type of one of the RxPDO, such that it accepted synchronuous transmission. What made it even more difficult in my particular case was that the EDS file of the CANopen Slave device had marked the RxPDO with ReadOnly (RO), so I had to manipulate the EDS file in order to make it configurable in e!C… Anyway, it worked after I did this change.
@WagoTorgeir this was exactly the problem, but I was lucky in that it wasn’t read only and I was able to change from asynchronous to synchronous communications in the connection configuration. Now the PLC is continuously communicating with the devices and they are not falling asleep.
Thanks to the entire WAGO team for pointing me in the right direction!
