We have two GE make Gas Turbines in our plant. Earlier both Gas Turbines were controlled by Mark IV controller. These two controllers were interfaced with our Plant DCS (Honeywell make TDC 3000) through Hiway Gateway. Both controller outputs were connected to Honeywell PLCG card (Port-1 for GTG1 & Port-2 for GTG2). Here DCS is working as Modbus Master and Mark IV controller as a slave. Protocol used for this communication was Modicon M584 through RS232 port. Recently we upgraded one of our Mark IV controllers to Mark VIe controller and other is running on old Mark-IV controller. So in PLCG card one port is connected to Mark-IV and other is Mark-Vie.
Mark Vie control system working on Ethernet protocol, so we use one Ethernet to Rs232 converter (Make-Lantronix, Model-UDS/Xpress DR IAP) b/w Mark Vie & DCS. But we are not able to established communications. We used Modscan32 software to test connection on Laptop and find information is coming from both side i.e. from Mark Vie and DCS separately but when we connect both end in converter we find communication fail. We checked this converter and found Ok. We also checked configuration (baud rate 9600, Stop bit 1, Parity- Even, Byte-8). We have only configured Analog and Digital points.
Please if anyone have such kind of experience please give me some idea to resolve it.
Have you updated the Lantronix box with the Modbus firmware. Some models can take ordinary Serial Server firmware or Modbus firmware.
Have you also checked the obvious things like the Modbus IDs are correct, you can ping the Lantronix box from the other end of your Ethernet connection. Sorry if these are too obvious but it is worth double checking.
Yes, I have upgraded firmware of Lantronix. I have also checked Device ID and Communication through PING command.
Is the modbus protocol ASCII or RTU? If it is RTU, it can be problematic on how the binary message is broken up and reassembled - you probably would need special firmware for modbus firmware as indicated elsewhere. ASCII protocol is more robust in this environment but it 'depends'.
Hope this helps
You are right, It is RTU and there are some issue in Data conversion. How can i check data frame both side? Is there any software for checking it through Laptop?
If I'm correct, it sounds like your Modbus Master is Modbus RTU through RS232 and your slave is either talking Modbus RTU over ethernet or else Modbus TCP. Either way, you are definitely going to need an actual Modbus gateway device, not just a standard ethernet to serial converter. A few ethernet to serial converters allow you to specify a default remote IP address to send serial-originated traffic to, but most assume the device on the ethernet side will initiate the TCP/IP connection. If your device is talking Modbus TCP, then you really need a gateway, since the protocol packets aren't even the same. I'm not familiar with the Lantronix specs, but even most Modbus gateways assume the Modbus master is on the ethernet port and the slave is on the serial port. You will need to check with the gateway mfg to see if your configuration is supported.
I think the physical layer is the opposite of TK's layout, based on the OP's statement "Mark Vie is on ethernet".
I propose the layout as:
Mark Vie is on ethernet, as a slave, maybe Modbus TCP, although not explicitly stated. Honeywell DCS is Modbus RTU Master on RS-232
Wildcard: could the OP reference to "Protocol used for this communication was Modicon M584 through RS232 port" mean that the communication is/was Modbus Plus? If so, that's a different ball game altogether.
Since Modscan 32 is available as a test Modbus master, I'd suggest using the serial port on the laptop to connect to the serial port on the Lantronix with the MARK on the ethernet side in order to test the Lantronix setup, substituting Modscan32 for the Honeywell DCS master.
I remember climbing the Lantronix learning curve. Some highlights:
An out-of-the-box Lantronix DR-IAP serial server bridge needs
- to be assigned an IP address
- Modbus firmware loaded into it
- its Modbus serial parameters configured
I have never encountered a DR-IAP that was ready for Modbus out-of-the-box. I have always had to install the Modbus firmware. I figure if Lantronix has Modbus firmware, it's needed to do Modbus, otherwise, they wouldn't have done the work for a specfic driver.
The tasks are accomplished with Lantronix's "Device Installer" software. The latest version of Device Installer software should be downloaded from Lantronix web site. The Device Installer software and/or Modbus firmware on the CD in the box is likely to be out-of-date. I strongly recommend checked the Lantronix web site for the latest Device Installer and firmware. A year ago, the DR-IAP was designated as an "External Device Server", XPress-DR-IAP on the Lantronix site.
When communicating for setup via ethernet, direct connection from PC requires a cross over cable, or connection through an ethernet switch with straight through ethernet cables.
The Lantronix serial ports use either an RJ-45 connector or screw terminals. The RJ-45 can be confused with the ethernet port. And the RJ-45 serial port is switch selectable for either RS-232 or RS-485. And of course, there's all the port wiring issues for either serial link
coming into an RJ-45 or the screw terminals. The serial Rx blinkie LED should confirm whether the Lantronix 'sees' a Modbus poll from Modscan.
I remember wiring the DC power through a toggle switch when setting up the Lantronix box, so I suspect that it needs a power cycle after setup changes in order to recognize the changes. Consider cycling the power after making changes.
When you install Lantronix's Device Installer, if you consistently win at Lotto, continue on. If not, restart Windows.
The first task is to confirm or assign/change the DR-IAP's IP address. Launch Device Installer and click 'search'. There's a big button on the task bar to assign an IP address. It's a wizard. Follow the steps and tell the DR-IAP's MAC address on the paper label on the side.
Again, if you consistently win the Lotto, let it get its IP assigned from a server on the network. If you don't want late night calls about why comm with the generator failed, assign it a static IP.
Once that task is accomplished, Device Installer should find the DR-IAP on the network, identifying it with its MAC and IP address.
To install the Modbus firmware, click on the Device Installer's Update button. Select the default 'custom' installation, browse to the Modbus file (.rom) location, and complete the wizard for installing the Modbus firmware.
To configure the serial parameters, you can NOT use the web browser (or web configuration tab in Device Installer) with the Modbus firmware installed. You must use telnet to access the serial setup.
Go to the Telnet tab, click on connect, click ENTER and work your way through the serial setup screens.
Remember that Modbus ASCII is a 7 bit word; Modbus RTU is an 8 bit word.
When you select RS-232 in the telnet setup, you must also select RS-232 on the slider switch on the front panel of the DR-IAP.
Once it's configured, the blinkie LEDs are helpful in determing what's going on.
Connect Modscan32 to the serial port and the MARK to the ethernet port and have a go at it.
Can we add an additional Communication module in the existing Mark VIe system which can support RS232 Modbus protocol with DB9 connector?
I have done all the activities you mentioned in your post. In Lantronix module Tx & Rx LEDs are blinking continuously with out error but still we are facing same problem.
Can you confirm that the Mark does Modbus RTU, not Modbus ASCII, not Modbus Plus?
Does Modscan make a connection? Or does it give a 'no connection' error?
If Modscan connects, what error code does it return?
What is the IP of the Mark?
What is the IP of the Lantronix?
Is the Lantronix master or slaven in the serial settings?
Is this communication something you are trying to implement without GE's help, or the without the help supplier of the Mark VIe if it wasn't GE directly?
Where is the Ethernet connection of your converter plugging into the "Mark VIe"? To a VLAN switch? To a PDH port or a UDH port of the VLAN switch? To a card in the Mark VIe?
There is usually a drawing provided with the Mark VIe title "Network Topology Diagram" (or something similar; it's also, called ML 4108 or the 4108 drawing sometimes). It should depict any communication connections that were purchased with the system. Is this communication link shown on that drawing?
If this is something that you purchased with the Mark VIe control system upgrade? Why isn't the supplier helping you with getting this to work?
How does the Mark VIe know that it's being talked to? What IP address and subnet mask have you assigned to the Ethernet port of the Lantronix?
There are generally two Ethernet-based LANs for most Mark VIe installations: the PDH (Plant Data Highway) and the UDH (Unit Data Highway). The HMI communicates with the Mark VIe via the UDH, and GE doesn't usually allow direct connection to the UDH. Communication over the UDH is via a proprietary version of GE EGD (Ethernet Global Database) Ethernet protocol (if that's the right word for it; it's still proprietary even though it's Ethernet-based).
The Mark VIe can also have a communications card that can communicate via serial MODBUS. There is also an option for MODBUS over TCP (see the Mark VIe System Guide, GEH-6721; there should be at least an electronic copy on the HMI provided with the Mark VIe).
The Mark VIe can communicate via MODBUS in several ways. The most common is through the HMI, either serially or via the PDH Ethernet LAN, which is still another option, but it's done through the HMI, not directly with the Mark VIe.
So, depending on where you're trying to connect the "Ethernet" cable from your converter you may or may not be talking to the right "controller" (either the HMI or the Mark VIe), and you may not be using the right communications method.
I suggest there's nothing wrong with your converter, just how you're trying to connect it. The details are very sketchy, and if you're trying to do it without GE's or the control system supplier's help, you may find it very difficult indeed (as you are seemingly finding it now). "Ethernet" is not always "Ethernet".
And GE isn't the only manufacturer who does these types of things, using Ethernet as the "medium" but using a proprietary communications "language" (protocol?) for the actual commands and data.
[Pardon me if I don't get my topologies and protocols and mediums and layers all correct. APSTNDP is it? All Pilots Strive To Not Destroy Planes is the mnemonic, as I recall reading once. A LONG time ago. And that's as much as I remember. It either works, or it don't.]
I was waiting for your reply. However, both the vendor service engineers (GE and Honeywell) had came here for this problem and told that their communication is ok, but as a hole we are facing same problem. Both vendors had worked together but the problem still persists.
I am sharing some information for your references...
In our system Ethernet connection of Converter is plugging into VLAN switch's (Make- Allied Telesis, Model- AT-8624T/2M) UDH port.(Port no-12, IP address 192.168.201.244). This switch is connected to HMI. These entire configurations were done by GE- India. This was i asked to GE engineer but he told me that there was no problem about PDH and UDH.
I am also agreed with you, there is no problem with converter. My doubt is on Data framing. I think there is a mismatch b/w Master Poll and Slave Response.
How can i check this configuration in Mark - Vie HMI?
If someone implemented this through Honeywell HPM then please help me.
GE has changed the way they implement MODBUS communications so many times in the last few years it makes one head swim (meaning that it's very confusing and makes one feel light-headed and the brain is muddled).
So, it seems that GE is trying to implement MODBUS via the HMI. It has been reported on control.com that HMIs now use ControlST, which includes WorkstationST, for communications with the Mark VIe. This replaces something they used to call TCI (Turbine Control Interface), and I've not had a chance to work with it.
For a while recently they were using CIMPLICITY's MODBUS feature.
I really don't know how to tell you to proceed, but it surely seems like there's something amiss somewhere, and it's likely not with the Lantronix device.
I don't know how they have divided up the ports of the VLAN switch, so I don't know if the cable was plugged into the PDH port, or the UDH port, or the ADH port, or a trunk port. I would think the Network Topology drawing should list which ports are dedicated for which purpose. The VLAN switches are managed switches, and the ports are divided up between different functions. So, it is important that the MODBUS cable be plugged into the proper port. The fact that the IP address is 192.168.201.244 suggests that it's designated for the PDH.
But, you didn't say which subnet mask the Lantronix was set for; it's makes a difference. It should be 255.255.255.0 to work properly with the VLAN switch and the network configurations that GE uses, I believe.
I have heard that the Mark VIe can be either a Master or a Slave, but I don't know how to confirm or check that. I would imagine it would be done via some setting in ToolboxST, but since the communication is being done "through" the HMI, I don't know if that's correct or not.
But, I'm sorry; I don't know how to tell you to check to see if the Mark VIe is properly configured to communicate via MODBUS TCP. I'm not familiar with the method that is apparently being used at your site. The only one I've heard about involves using a dedicated Mark VIe card and I/O Pack for serial MODBUS communications. The serial cable was plugged directly into a port on the card, and the Mark VIe I/O Pack was programmed for MODBUS communications. I wasn't able to look at ToolboxST and the .tcw file, so I don't know how that was done in the Mark VIe. So, unfortunately, I can't be of much more help than this.
And, I don't have a UPD (dongle) and a copy of ToolboxST to be able to look up how MODBUS might be set up. But, if you do, try looking at the 'Help' files of ToolboxST. Also, the HMI should have a lot of manuals and literature in .pdf format; you may find a Mark VIe MODBUS manual or write-up that may be helpful
Please write back and let us know how you progress!
I have checked all the things once again and describing those data for your better understanding. Here DCS is working as Modbus Master and Mark Vie is working as a Slave.
In DCS side (Honeywell make TDC 3000) we used PLCG (HG) card to communicate with Lantronix (Screw Terminal) through co-axial cross cable (3-wire connection, RXD,TXD & GND). There were hard Jumper settings in this card for configuring communication. The settings are:
Baud Rate: 9600,
Byte: 8 bit,
Stop bit: 1,
Protocol: Modicon M584,
In Mark Vie side R,S,T controllers are connected with CIMPLICITY - HMI through VLAN fast Ethernet switch, make Allied-Telesis, AT-8624T/2M( UDH port). Lantronix Device (Ethernet to RS-232 converter) is connected to HMI through same VLAN switch.
Settings of Lantronix through Device Installer are given below:
Modbus/TCP to RTU Bridge, RS 232
Model- Device Server Plus+, Firmware Code-DA, UDS 100/Xpress DR IAP.
Baud Rate: 9600,
Byte: 8 bit,
Stop bit: 1,
I can able to fetch the Data Mark-Vie data through Lantronix Screw terminal in my Laptop using Modscan32 software.
I can also able to fetch data from PLCG card (DCS) in my Laptop using Modbus Slave software. I am able to get both side data in my laptop when testing separately. But when I connect both the end then I am not able to get data in DCS. I have checked mapping addresses both side and found addresses are same.
One observation is both Tx & Rx LED of Lantronix device are in steady condition (Amber Color). Error LED is not glowing.
Is there any possibility of Master Polling and Slave Response? (DCS is slower than Mark-Vie). I can't able to address where the problem really persist?
Please understand that Honeywell does not publish documentation for its DCS systems on the web, which means that the functionality of cryptically named devices (like PLCG) is a complete mystery, unless you tell us what it does. We forum participants have no means of deciphering proprietary terminology because the technology and terminology is wrapped in secrecy.
Given the information you've provided, I suspect that your Honeywell DCS is not acting as a Modbus master, I suspect that it is acting as a Modbus slave.
1) >I can able to fetch the Data Mark-Vie
>data through Lantronix Screw terminal in
>my Laptop using Modscan32 software.
Great! This establishes that the Mark-Vie is a Modbus slave and talks Modbus TCP through the Lantronix.
2) >I can also able to fetch data from PLCG
>card (DCS) in my Laptop using Modbus Slave software.
This does not make sense to me.
Modscan32 is Modbus Master software, and while it makes sense that you can fetch data from the Mark-Vie (a slave) with Modscan32, it does not make sense that you can fetch data from the PLCG card to your laptop running Modbus slave software. A Modbus slave (laptop) cannot query and fetch data from another Modbus slave (DCS).
Did you mean to say that the PLCG card in the Honeywell DCS, running as a Modbus master, can fetch (or write) data from (or to) the laptop, which is running Modbus slave software?
Or, do you mean that Modscan32 (Modbus master) software on your laptop can fetch data from Honeywell PLCG card ?
3) In your initial post, you stated, "Here DCS is working as Modbus Master and Mark IV controller as a slave." I'm doubting the "Modbus master" part of that statement.
In your latest post, you state:
In DCS side (snip)
Baud Rate: 9600,
Byte: 8 bit,
Stop bit: 1,
Protocol: Modicon M584,
Modbus Masters do NOT have slave node addresses. What is "Device ID"? "Device ID" sounds to me like the setting that defines the port's address as Modbus slave #1. A Modbus Master would not have a slave node address.
4) You can read data from the Mark Vie with Modscan32 through the Lantronix, so that half of the comm link is working. The other half of the comm link is getting the Honeywell Modbus master to operate.
How have you proved that the Honeywell Modbus master is working?
Could it be that you've only tested the Honeywell DCS as a Modbus slave, reading data from it with a laptop Modbus master? Doing so will not accomplish your initial stated goal of Honeywell DCS master/Mark slave.
It isn't clear how you've tested the Honeywell where it functions as a Modbus master, where it initiates the reads or writes and handles the replies from a slave. And, the settings on the DCS side indicate that the DCS port is probably a Modbus slave port.
PLCG is an Interfacing Card used in Honeywell DCS for Third Party PLC. In this card there are two RS232 port (Port1 & Port2). In my first post I already said that we have two GTG. Earlier both had Mark-IV control. These two Mark-IV controls were communicating to DCS through single PLCG card (Port-1 for GTG1 & Port-2 for GTG2). We only upgraded GTG-1 control from Mark-IV to Mark-VIe. At present GTG-2 is running (Mark-IV control) and is communicating with DCS perfectly. Earlier both Mark-IV controller and both PLCG port have identical configuration. Where DCS was working as a Master and Mark-IV was Slave.
We didn't change any parameter in DCS side. Only thing we have done that we connect same cable (earlier used in Mark-IV controller) to lantronix screw terminal.
I have checked DCS configuration and it is working as "Master" based on Modicon-M584. There is no doubt on it because other GTG2 is communicating perfectly.
In Honeywell DCS Device ID means port address where the slave is connected. In our case it is 1 for GTG1 and 2 for GTG2.
I used SimplyModbusSlave2.0.2 software for checking DCS data. This software virtually converts my Laptop as a Slave. In the LOG file of this software I found that DCS is requesting for data.
Same PLCG card is working fine in case of GTG2 (Though GTG1 & GTG2 have same configurations) but it is not communicating in case of GTG. Same serial configuration data we configured in Mark-VIe (GTG1) through Lantronix device installer (in Telnet, port 9999).
My question, is there any difference between Lantronix RS232 output and Mark-IV serial interface card (used in running GTG2)? What will be happened if "Modbus Master" is slower than "Modbus Slave"? Will it affect data communication?
I work for Lantronix Technical support, and spotted this. As the unit is a Lantronix part I would recommend contacting us at Lantronix Tech Support line at 800-422-7044. As I think we might be able to help you on this.
It occurred to me that when configuring the serial side of the Lantronix DR-IAP (using Telnet), the Lantronix serial side can be configured as either Modbus master or Modbus slave.
Since the DCS is the Modbus master on a serial port, the Lantronix should be configured as Modbus master.
Please tell me your problem is now solved or not. If so, how it was solved?. We have similar problem that Modbus data update is not working between Honeywell EPLCG and Lantronix Express DR. The communication is working fine by all means, but the data update is not working. Please update me if you had come across with any solution.
Have you considered using OPC for this architecture?
You will need the following:
- OPC Server for Honeywell TDC 3000
- OPC Server for MarkVI
- OPC Data Manager to link those two systems together:
Let me know if you have any questions.
Global Solutions Architect
We had serious trouble establishing the link between Mark VIe and Yokogawa Centum VP DCS over Lantronix, but finally managed it .
1. Upload the Latest modbus firmware from Lantronix website to the device over Lantronix device installer using straight Ethernet cable.
2. Configure the host ( in our case Enet2 port of R Controller ) as host and give its IP in the Network Adapter 1 of Toolbox ST General tab. ( You are setting the host and its IP). Our Host IP was 192.168.10.73 and Lantronix IP was 192.168.10.75
3.Set the IP of the host in Lantronix setting ( Set 2 in Slave/Master settings and then assign IP of R core Enet2 port in Lantronix). A ethernet crossover cable is required between R core and Lantronix.
4. Using ModScan 32 over Rs 232 you can check if data is coming through.
5. we missed step 3 and struggled for 2-3 days.