I have something not clear in my HMI modbus communication with DCS we are using GE MKVI control system, the communication with DCS through cimplicty using TCP/IP. When we restart the computer sometimes the communication with DCS established directly and sometimes we are getting a message in cimmod.log as below:

Cimplicity Modbus Server Program is starting.<pre>
Reading IO_PORTS.DAT file...
Slave Id = 1
Cimplicity project = SKIKDA
Data Type = RS16 Non-Native
CIMPLICITY site project name = SKIKDA

Cimplicity Data Thread is starting.
Cimplicity Fetch Thread is starting.
Cimplicity Fetch Thread is ready.
Waiting for connection on pipe "\\.\pipe\SKIKDA_MODBUS".</pre>

Until stop and start the project again ,sometimes we need to do this action many times or restarting the computer many times also.

When we did the netstat dos cmd the communication established with socket 502...

Could somebody please clarify what is the reason for this behavior.

many thanks in advance...........

 

As always with something that was working for some period of time but has "suddenly" developed problems or issues:

<b>WHAT HAS CHANGED?"</b>

Was something changed on the HMI end of the link? Did someone try to add a signal or signals to the CIMPLICITY project or build the hmb device?

Did someone make some changes to the DCS end of the link?

 

Thank you for your reply. sometimes we add some signals and build HMB file as useful for commissioning.

Also, DCS engineers changed the configuration of network between HMI's and DCS they used a routers to separate between control rooms and avoid access between them.
After this modification we are getting this message.

Is there any action we can do to solve this problem?

Thanks again....

 

Dear attali abdelkrim, as CSA asked "When did this problem start?". You anwered after changes to the .hmb file and also changes to the network.
From the snip of cimmod log you provided it looks like you are using the TCI cimmod protocol. Signed 16 bit integers, non-native format,using ethernet as the port type. TCI indicates it is running, the connection is ready, and waiting for a connection from the modbus server.

I suspect if changes have been made to the network then that is where the problem is. You need to look at network connections and especially focus on routers. Make sure a gateway is setup if trying to pass through a router. I assume you have some server setup on the plant data highway, trying to communicate with the cimplicity HMI that is running as a modbus slave. Again from what I see the slave is ready to communicate, but the server seems unable to reach it.
Please let us know how your diagnosis proceeds.

 

Hello,
Try use wireshark to test what is going wrong with the Modbus TCP/IP communication.

Regards,
Andrzej
www.modbus.pl

 

Hi,

Are you using ABB DCS, if yes please check the configuration on DCS side, ensure it is 'Modbus TCP Gateway' not 'Modbus TCP'. Mark VI Modbus TCP is not a pure modbus TCP, it is a Mobus RTU over Ethernet but GE claimed as it is a Modbus TCP.

 

Hi,

> Are you using ABB DCS, if yes please check the configuration on DCS side, ensure it is 'Modbus TCP Gateway'.

We are using Honeywell DCS.

Thanks.

 

Hi Andrzej,

Sorry, I do not understand what you mean by wireshark, could you please explain how we can do this test.

Many thanks.
Karim

 

attali abdelkrim,

>> Are you using ABB DCS, if yes please check the configuration on DCS side, ensure it is 'Modbus TCP Gateway'.

> We are using Honeywell DCS.

When you post to a forum like this with a problem, you need to provide as much information as possible in order to receive the fastest, most concise and most appropriate response.

You still haven't answered the question of when the problem began. If the problem started after you made changes to the MODBUS configuration on the HMI or in the DCS, this would have been good information to include in the original posting. You should have back-ups of the original files you can restore from to get the system back to known, working configuration if this is the case. Then you can try making changes, one at a time, to see which change is causing the problem (because many times people make multiple changes and only one or two of them are incorrectly configured and causing the problem).

If the problem began after the installation of the new network switches, then it would be pretty clear that the configuration of the switches would be to blame. This, too, would have been good information to include in the original posting.

As MIKEVI says, it appears the GE Mark VI HMI is ready and waiting for a signal from the DCS (it is, after a "slave" to the DCS) to begin communications. If the DCS can't connect to the HMI because of the incorrect or incomplete configuration of the network changes (possibly including the GE Mark V HMI network settings/configuration which may need to have been modified to communicate with the DCS through the new switches) then the GE Mark VI HMI won't be able to send any information.

Again, whenever any problem like this occurs on a system which was working the best question to ask is, "What has changed, or what was changed, to cause the problems to start?" While GE HMIs are known to be user-unfriendly and poorly documented, if the entire system, including the DCS, was working and then it suddenly is not after the network was modified, it's a safe bet that the network modifications were either incomplete or incorrect. And, that's not a problem with the GE Mark VI HMI or the software on the GE Mark VI HMI. It may be a problem with the configuration of the PC, the NIC, or the software--because it was once working and to make it work with the new network configuration it needed to be changed--but it's not likely a sudden problem with the GE Mark VI HMI or the software which was running before the network was modified.

I have been at many sites where the "IT (Information Technology) department" came in and changed the GE Mark network configuration for whatever reason (usually for "network safety") and didn't do it properly or completely. The problems were self-inflicted, but blamed on GE.

 

Hi,

We did 2 actions in same time we restored the MKVI HMI using the original backup image first and we changed the network configuration at this time the problem began.

We checked the physical communication to DCS using DOS CMD ping/netstat, we can ping the DCS server and also the communication established.

Moreover, we used some Modbus simulator to communicate with HMI but the same problem. how we can check that GE HMI is not able to send information?

Thanks

 

CSA and Originator of this thread.

I do not know very well Honeywell DCS. But I have a great experience with ABB DCS.

On one site it was almost a fight between DCS and Turbine OEM. The DCS side claimed they cay have a connectivity with other PLCs but GE Mark VI. In fact it was working and sometime not working. It was going on several month until site is able to get hold of a knowledgeable DCS engineer.

From Wireshark and other Mark VI Modbus diagnostic tools everything seem to work as expected. From Mark VI perspective it was waiting for connection.

From DCS Function Block the link seem to be established but no communication.

It turned out the problem happened when they is a switch over on redundancy modbus link or HMI rebooting. The only way to solved the problem was keep on stop and start TCI until the communication is established basically it is a Russian Rullet game.

Situation even getting worse when Tubine OEM using Wireshark, Mark VI Diagnostic Tool, and Modscan and claimed that everything is normal. On DCS side they also use other tools (counterpart of Modscan to simulate the slave) and claimed DCS is normal.

Finally when we get the Knowledgeable DCS guy onsite he found that it is the way DCS managing there redundancy. Master Communication Module always requesting information module from HMI but Standby does not requesting information so no replied from HMI(It way the way if of handling thing on Modbus TCP Gateway and customize routine on DCS). When the switch over happened or HMI reboot, the connection is not happened randomly. Problem on site was solved by configured the DCS to be Modbus TCP Gateway instead of Modbus TCP and rewrote the redundancy routine on DCS side.

Other site that I experience with ABB DCS was done by other approached. Previous OEM Field Engineer he had un-teamed the NIC on HMI, in this way there are two separate network interface on DCS. On DCS side they configured as normal Modbus TCP and no need for special handing on redundancy routing. But the bad side for this setup is everything was doubled. (OPC,communication task, this site is Mark VIe unlike the previous one which is Mark VI) so it turn out that too much loaded put on the HMI. Which also cause the communication failed randomly. Anyway this is a side stories.

Mark sure that your site is not in a similar situation.

 

attali abdelkrim,

It's not clear why you restored the HMI from back-up disks.... And, the fact that you took the "shotgun" approach makes troubleshooting that much MORE difficult. This admission adds more credence to my belief that we don't know the whole story about what's been going on at your site, and without understanding the situation and everything that's been done and why, it is virtually impossible for us to be of much more help.

I think Green_man has provided quite a lot of very good information for you to review and use in your troubleshooting process.

Lastly, I have had very bad luck with restoring HMIs from back-ups. By that I mean, it almost never works on the first re-boot after the disks are re-loaded. It usually takes several hours, at least, and a couple of days usually, to work out all the kinks. Part of that is because usually I arrive to find the most recent back-up disks are a couple of years old--at least. The other part is that, as has been said many times before on control.com: GE HMIs are not very user-friendly, are poorly documented, and are basically a kludge of software bits and programs that all have to be tweaked "just so" to make the work correctly.

Even if you had a very recent set of back-up disks and the GE HMI powered-up on the first try, <b>did you restore the DCS MODBUS configuration to the same one that matched the GE HMI back-up disk configuration?</b>

Usually, when the IT department comes in and puts in new network switches, they change IP addresses and subnet masks, and if you restored from an old configuration prior to the network switch change, did you change the old IP addresses and subnet masks to match the new configuration?

Lastly, there are MANY "embedded" IP addresses in GE HMIs, including network drive mapping. And, worse, there are many unwritten "rules" about network addresses and subnet masks in GE HMI configurations. It's best to get GE involved when making such changes, because only a couple of people in GE even really understand all of the nuances and expectations and requirements and things which just can't be done no matter what, now how, no way. Things which would seemingly be possible for most networks--but not GE implementations.

It's highly recommended you get someone from GE to site. While you're waiting for them to arrive, draw up a time-line of all of the things which have happened at the site with the MODBUS configuration and network configuration so that you can accurately convey everything that has happened and when.

The solution may be very simple--but that may only be because GE knows the reason! Help them help you!

Best of luck!