hi CSA

please CSA can you help me? i need your help

so
DCS communicate with MARKVI

1. HMI (PDH and UDH)
2. getway

when we loss communication with HMI you can

communicate with GETWAY

<b>Moderator's Note:</b> Not sure if GETWAY should be Gateway.

with the GETWAY there is toolboxST. i have problem of the communication when i open the workstation of the getway. i have find there is problem so the problem is: modbus Error

can you help me CSA with this problem
MODBUS ERROR is not OK?

what is the solution please?

 

First of all what DCS are you trying to link to? MKVI has a GSM protocol they use that is very robust. It works well with most Modbus interfaces.

 

the DCS is EPKS Honeywell

the communication before is very well

MARK VI communicate with DCS with protocol PHD and other link is with GETWAY

because when we loss communication with DCS you can communicate with getway only alarms ok?????

>First of all what DCS are you trying to link to? MKVI has a GSM protocol they
> use that is very robust. It works well with most Modbus interfaces.

 

dear ALL

i need your experience. i verify this morning the gateway works station so i have find:

1. all program are removed (MODBUS, configuration) but the application of toolbox St exist. so my question how i can solve this problem and to get the communication and also to establish?

2. in turbine frame 5 double shaft MS5200D at the startup, the temperature of exhaust after fire, warm up are 590 C°. but there is some problem of SRV valve because this valve have problem of max opening so mechanical problem. the max is 60%; which parameters i will verify?

what is the solution for 2 problems?

please ALL give me your experience

 

> 1. MODBUS

If you use Closed Source Software you need to search for additional debugging tools, because you can't simply insert debug printf() statements into your Open Source Software.

In case you use Modbus TCP a network sniffer like
https://www.wireshark.org/
might be used as debugging tool.

It might alternatively be sufficient to simply use the command line sniffer tcpdump
http://www.tcpdump.org/manpages/tcpdump.1.html

If you use Modbus RTU please
google: rs232 rs485 sniffer
and use a hardware sniffer.

 

H A R,

This SRV "problem" seems to be related to this (old) thread:

http://www.control.com/thread/1289667103#1402353260

So, it's been going on for a long time.

And there's a very recent thread which you can use to help with this issue:

http://www.control.com/thread/1413491312

You need to monitor FPRG and FPG2 when the unit is accelerating and fails to reach rated speed. They should be equal--if they are, then the problem has absolutely nothing to do with the SRV (presuming the gas fuel supply pressure upstream of the SRV is at about 17 barg or so). As was noted, contrary to popular belief the SRV does not go to 100 % during normal operation--ever. Unless the gas fuel supply pressure is low, very low, and the require flow is high, higher than the pressure can support.

If the exhaust temperature is too high (TTXM equal to TTRX) during starting, then the GCV will be "limited" to prevent causing an exhaust overtemperature alarm. Possible causes are many and may actually be a combination of one or more issues: dirty compressor; a worn-out machine in need of maintenance/refurbishment; dirty turbine inlet air filters; high load on the LP turbine; problems with the second-stage nozzle control/actuator; problems with the axial compressor IGV control/actuator; and so on.

The problem could also be a bad GCV LVDT "calibration", but most newer Speedtronic turbine control systems use acceleration rate as a reference and will try to increase fuel--until the exhaust temperature reaches the exhaust temperature limit (which is usually around 590 deg C during acceleration!) at which time FSR (which drives the GCV) will be "limited" to prevent an exhaust overtemperature. And, if this is happening (excessive exhaust temperature during acceleration) then the unit may not reach rated speed.

Yours is a two-shaft machine, and so there are some differences but many similarities with the SRV/GCV and exhaust temperature limits during acceleration. Also, most of the possible causes are the same--with the exception of second-stage nozzles and LP load (which single-shaft machines don't have to deal with).

As for the gateway issues--if the MODBUS/gateway communication programs are not on the CPU, how the he__ did they get deleted? And why? For this issue, it's recommended you get someone from the OEM/packager to site to assist with restoring the gateway--if there are no back-up DVDs (which could be one solution if they are recent and complete!). This just goes to further reinforce the critical importance of making frequency back-ups of working CPU configurations so that when programs "disapper" a back-up/re-install can be used to restore a working configuration. This isn't something which can be done via a forum like this (telling someone how to install this or that program and configure this or that file and enable this or that service/application). It must be done using a known working back-up, or by someone knowlegedable in the configuration of such a system.

Getting back to the starting issue--if FPG2 is equal to FPRG (sometimes on some units FPG2 is called FPG1, or 96_fpg2x, where 'x' is 'a', 'b' and 'c'). But if the actual P2 pressure and the P2 pressure reference are equal then the SRV is NOT the problem. And, if TTXM is equal to TTRX during acceleration and when the speed begins to level off before reaching acceleration--then something is causing too little to flow through the turbine or the LP load is too high. OR, someone has tried to increase the acceleration rate too much....

Please write back with the details of troubleshooting and resolving the inability to reach rated speed. Provide all the requested information (FPRG; FPG2; TTRX; TTXM; all Process- and Diagnostic Alarms annunciated during acceleration, and even prior to starting); gas fuel supply pressure; FSR; FSG during the leveling-off of turbine speed. If you want more help, you must provide more detailed information. And, if you solve the problem with the information provided, please write back to tell us what you did and how you resolved the problem. Many people read--and follow--these threads. Not only know, but in the future. Feedback is very important to let others know how problems like this were resolved.