DCS-Mark V Communication

Good morning

at first I apologize for my bad English, and I hope this is the right section to do my questions. I would like to ask you help about a problem with the communication between DCS and MakV.

In particular we have two turbine unit controlled by MKV and one DCS system. Each turbine unit have one PC HMI (HMI TG1 and HMI TG2). The configuration of the PC HMI offer the possibility to control both TG1 and TG2 with only one PC HMI.

During last week we noticed that the communication between the systems falls and DCS doesn't read the data from MKV. I opened the page of DCS's application where, in normal conditions, there are a list of parameter read from MKV. In this case there was a long messages list with a series of "Point Cmd not definite IDHint: number", and one of the last (not the least) was: "Point not definite : Controller T1 Point Name L30VL2" (this is strange because L30VL2 is the feedback from the power distribution).

After a long series of effort I restart the communication in this way:
stop the TCI service on the HMI
stop the RCE_GSM on the DCS Client
then start TCI and RCE_GSM

At the moment remains the problem of the list of not definite points that (I suppose) sometimes cause the stop of the service (from the DCS, because on the HMI the GSM application continue to run).

My questions are:

- do you think I have to continue to looking for a problem on the HMI/MKV side or there should be a problem with DCS?

- How GSM manage the communication to DCS? In other words, in one HMI master and the other slave (or stand-by)?

- I saw that the hard disk of the PC HMI TG2 have one more partition than the other HMI. This partition is named HMI(D. This means that in this section there are files for the HMI functions, or those files are in the partition G: where are GSM.exe files and other .exe files?

- do you think it could be helpful recompile the GSM database in order to be sure all points are correct? If yes, can you send me a procedure to do this operation?

I hope to have given you information clear enough to understand my problem.

Thank you very much in advance
best regards

fnc,

GSM (GE Standard Message Protocol) is a pretty simple system in that it's really just a list of Mark V CDB (Control Signal Database) signal names--no special addressing/referencing required (like with MODBUS). The GE Mark V HMI is a "slave" and the DCS is the "master" and the GE Mark V HMI responds to requests, some of which can be set up as periodic lists to be transmitted on a regular basis. (I think all of this is described to some extent in the GE Speedtronic Mark V HMI Manual--sorry I don't recall the GE publication number, but you should be able to find a .pdf version on the GE Mark V HMIs hard disk.)

The majority of GSM problems are the result of EITHER someone making changes to the Mark V configuration files and then running the batch file without resolving errors, or someone making changes to the DCS end of the communication link. If the signal names don't match, then problems like this can occur.

You told us the problem started about a week ago--but you didn't say what happened before the problem started. Was some "work" done on the GE Mark V HMI, and/or the DCS? The Mark V CDB is created by using some software applications on the GE Mark V HMI. It's common for people to make field changes to the Mark V configuration files (assignment files (.ASG files; .SRC files; etc.) and then run the "Total Job Complier" batch file: MK5MAKE.BAT to recreate the Unit Data Dictionary files. If there are errors or warning when the batch file is run, they must be investigated and resolved.

GSM communication is usually done over an Ethernet connection--are you sure the Ethernet connection/cables/switches are all in good working order? Along the entire length of the Ethernet link between the DCS and the GE Mark V HMI?

TCI can take a few minutes to get fully started and running. Whenever re-starting TCI, it's best to wait at least five minutes before re-starting CIMPLICITY because CIMPLICITY puts a heavy load on TCI and it needs to get running well before it can deal with CIMPLICITY's demands and other demands like GSM.

It's possible for the two HMIs to each be capable of responding to requests for data for either Mark V. The HMIs are only "windows" into the Mark Vs, they don't do any control or protection, so the configuration information on the HMI MUST match what was downloaded to the Mark V.

I believe if the two HMIs were to be configured as "either/or" for GSM communication, it requires the GSM to be the one doing the change in request address. I don't think it's possible for the two HMIs to know which one is the "primary" and "secondary" GSM responder--but I may be wrong about that. GSM is pretty simple, powerful but simple, but I don't if it was that sophisticated. The DCS has to sense a failure or communication with one GE Mark V HMI and then switch to the other, or switch by some operator-initiated command to the DCS. I don't think GSM can do that by itself.

The EXE directory is where all executable files which make the PC a GE Mark V HMI reside (with the exception of CIMPLICITY). GSM.EXE is one of the many GE Mark V HMI programs--but it uses files in the PC's RAM and from the F:\UNITn directories (F:\UNIT1; F:\UNIT2), not from the EXE directory. (Some newer GE Mark V HMIs use different locations for the unit-specific directories, UNIT1 and UNIT2--but they (UNIT1 and UNIT2) must exist in only one place on the HMI for it to work properly as a GE Mark V HMI. It's very common for people to make copies of the UNIT1 and UNIT2 directories on other hard drive locations, but GSM.EXE and the other GE Mark V applications only reference one UNIT1 and UNIT2 location.

Another VERY common cause of problems like this with Mark V is that if someone makes a change on on GE Mark V HMI to one Mark V, those files that were changed MUST be manually copied to the other GE Mark V HMI to the proper directory, and then that second GE Mark V HMI must be re-started to make the changes become effective.

I think you have to look at the DCS to see which GE Mark V HMI it is communicating with. I believe you can also on a command prompt window on the GE Mark V HMI, and if you type:<pre> GSM /?</pre>or<pre>
GSM /HELP</pre>and then press ENTER, you will get a help screen for GSM. If there's a switch/option for STATUS then you can probably type GSM /STATUS and press ENTER and get some information. There might also be a GSM_STAT.EXE file or something similar which might be helpful.

That's about all I can think of. GSM is a great thing when it works--which it does most of the time. But, when it doesn't it can be a difficult thing to troubleshoot. And, again--the overwhelming majority of problems are caused by changes made to a Mark Vs configuration, or the DCS configuration, or changes made on on GE Mark V HMI that weren't properly copied to the other GE Mark V HMI. After that, it's a hardware issue (Ethernet hardware). There have also been several reported cases of sites changing IP addresses on equipment and not completing the process properly and expecting the GE Mark V HMIs to be omniscient and complete the process automatically (GE Mark V HMIs aren't that sophisticated--trust me!).

Hope this helps! Please write back to let us know how your fare in resolving the issue, or if you need clarification.

CSA, thank you very much for your quick reply.

I will start the verification as soon as possible (in the next days it is possible there will be a stop of one machine so I can do more test).

You are right about the changes before the problem (sorry but in the previous message I was so focused on the problem to forgot to tell you the possible cause). On one of the two PC HMI we change the hard disk, putting in service one which we consider as a back up. When we restarted the PCHMI all function return in service without problem (monitor pages, command, forcing, and all other parts), at this point we were confident that all system was ok. After one or two stop of the service I thought that the changing of the HDD may have caused the problem. so, trying to fix it, I put in service the old HDD again, but after a series of attempts the situation doesn’t change, so I return with the back up HDD.

Now, with your information, I try to understand where or who is the problem. If you have any other advice, based on what said before, they are welcome.

I think I still serve your kind help. I will keep you informed about the situation.

Thank you very much

Hi!

I would like to give some more information about the final (I hope) solution of the GSM problem.

After GSA's information (I thank you very much again) we have checked the communication from MKV and DCS and was ok. But, when a particular signal from MKV to DCS was at one, after some minutes the communication went down. With the help of DCS's system specialist we have opened the database dedicated at the data exchange from the systems.

Reading the list we saw that the particular signal that was in error (the status motor feedback of one VL fan) wasn't in the list. Maybe it was forgotten from the beginning and not noticed because, in the past, there was no communication about it from MKV to DCS.

After the problem with the feedback was solved, we started again the GSM and the communication was ok. Later one GE's engineer came at our plant and did some adjustment on the cimplicity configuration, just to fix some other little problems. But the main issue was the fact that the MKV was giving at DCS an information that was not present in the DCS's database, this was leading at an exchange of "data error" from the two systems that bring the communication to fall.

Thank you very much!

fnc,

Thanks VERY MUCH for the feedback!