It's your place to connect with experts and peers, get continuous support, and share knowledge.
This forum is addressing industrial automation design & engineering, operations, asset performance, cyber security and digital transformation for Plants & Machines.
You can subscribe to this forum after you log in or create your free account..
Posted: 2021-01-22 03:18 AM
I'm working with Citect 2016 (update 38).
We need to establish a Modbus TCP communication with a PLC in plant. Nevertheless, the SCADA never gets to communicate to this PLC. After running many tests, we found out that the SCADA never sends any kind of request to the mentioned PLC (we used wireshark).
In order to rule out any kind network problem, we run a ModbusTCP Server in a PC which was at reach of the SCADA, but the results were the same.
After that we proceed to create an empty new project pointing just to the same testing ModbusTCP Server on the PC. But to our surprise, it worked perfectly well, even though the parameters (port, protocol, device, variable addresses) were the same as the ones in our original project.
It is the first time something like this happend to us. We have many Schneider M340 using ModbusTCP without any kind of problems.
Any ideas?? Thanks in advance
Posted: 2021-01-22 06:15 PM
What you did on using Wireshark is brilliant. And how you try to isolate the issue by setting up a new project and saw that MODBUS TCP actually works on new project but not the existing was also the correct way of isolation. This was the troubleshooting procedure I often did some 15 years back on Citect when faced exactly what you describe (and in many projects, not juts one). I would have thought such problem will not occur anymore, unless your project has a long history of migration from a very old version.
I hope this will work for you as it did for me. In the existing project, delete the IODevice, the Port and the Board. Then add them in again. This somehow worked for me. There seems to be something else at play behind the IODevice, Port and Board settings we can see. Good luck.
Posted: 2021-01-26 03:15 AM
Sorry for the late resposne, I've been off the office these last days.
Thank you very much for your piece of advice. I'll give it a try a let you know what happens. It sounds promising.
Posted: 2021-01-27 05:33 AM
Hi everybody !!!
Unfortunately I cannot say the problem is solved. Dispite of that, we discovered some interesting things.
As we had already ruled out any network problem, we are running now our test modbus server ( simulated IOdevice ) on the same pc the scada server is.
Before lauching the SCADA, we started Wireshark on the background. After checking out the log, we found out that Citect sends only one request to the simulated IODevice (which sends a response back), There are no more messages from that instant on. After 100seconds, the IODevice closes the TCP connection and that's it.
We tried creating again the interfaces, ports and devices but there was no luck.
"config.ini" does not configure any parameter related to MODBUS either.
Posted: 2021-01-27 07:16 AM
Sounds to me like your device does not response to a Read Digital Input @ address 40001. When Citect starts, if you look at the Wireshark traffic, you will see it always sends a poll for that. If the device does not response, Citect thinks the device is dead. This was my experience again from ages ago. And I did raise the issue to the Citect guys in the good old days.
Look into the MODNET Driver Help.. . See InitVar and InitVarType. Set them to something that your device will response to.
Hope this helps...
Posted: 2021-01-27 09:40 AM
This problem is really driving me crazy.
I've just checked again the Wireshark logs of both the production (which doesn't work) and testing (it works) projects and I can see that the Citect first poll and Device response are exactly the same in both cases, but somehow Citect refuses to keep sending requests in the production project.
I'll check again the "config.ini" to see if there are any differences.
Posted: 2021-01-28 06:03 PM
Well, when all else fails, we have to turn to AVEVA support. Hopefully your customer had purchased Customer First support.
Posted: 2021-01-29 12:50 AM
Wireshark controls the ethernet line. It does not check the integrity of the Modbus TCP protocol. For modbus control, you need to examine the packets coming and going to port 502. You can do this with Modbus poll software.
If there is no Modbus communication, connect your PC directly with the PLC. Switches in between may be closing the port. Or, when you make a Citect modbus query, if a query is sent to a register that is not on the PLC, there may be a problem in communication. For this reason, expand your modbus register table on the PLC side. Write a any value to the highest modbus address of plc.
Normally, I did not encounter any problems with the citect in modbus driver.