Mark VIe HMI Honeywell DCS modbus TCP/IP

Mark VIe HMI server and Honeywell DCS server(Mark VIe HMI-server,Honeywell DCS-client)are separated by a firewall cisco ASA5512.The client can ping the server but server cannot ping the client as per the rule in firewall.Is it possible to communicate them on modbus TCP/IP?Is it mandatory for server also to ping the client for modbus tcp/ip?
 
Because the client is the device that initiates the TCP connection, I don't believe the server needs to be able to ping the client. Just think about how you access web sites from a PC to the internet. Your computer can ping the web site, but the server hosting the web site cannot ping your computer.

However, you do need to also ensure that your firewall is not blocking the Modbus TCP port (502 by default).
 
Because the client is the device that initiates the TCP connection, I don't believe the server needs to be able to ping the client. Just think about how you access web sites from a PC to the internet. Your computer can ping the web site, but the server hosting the web site cannot ping your computer.

However, you do need to also ensure that your firewall is not blocking the Modbus TCP port (502 by default).
i too had the same thinking.is there any simulation software which can confirm this connection ? i dont have access to job site right now.
 
There are several Modbus simulator packages available.

WinTECH has both a master and slave called ModScan and ModSim: http://win-tech.com/

Simply Modbus also makes both master and slave simulators: http://www.simplymodbus.ca/

Witte Software also has both, with Modbus Poll and Modbus Slave: https://www.modbustools.com/download.html

All of the above are paid software, but have demo versions available that should be sufficient to confirm that the connection succeeds.
 
Well thanks for the reply.There are options of modbus and OPC both in the server of Mark Vie .But without taking too much pain ,we want modbus communication to act
 
sk1984,

I think you would find (or will find if you do more research and ask more questions) that the OPC option is much better than the MODBUS option, and will be less painful in the long run.

While I believe that both options require adding signals to the EGD in the Mark VIe to get them to the HMI (if you're going to use the HMI for MODBUS), if you want to use the MODBUS option of the Mark VIe directly (through a PSCA or the USCx if that's even still an option these days) that getting signals on the Mark VIe "direct" MODBUS is a lot more painful.

As with all standards, every OEM has their own interpretation--GE is no different with either OPC or particularly with MODBUS.

I would rather put my efforts into the OPC communication than trying to make MODBUS work--either via the HMI or the Mark VIe "direct" method and having to do work in both ToolboxST and on the HMI. I believe with OPC you can get time-tagging--which you can't with MODBUS, HOWEVER the time-tagging will be from the HMI not from the Mark VIe--but if the UDH uses NTP (time synchronization) at least you have a good chance that the time tags will be very, very close, whereas with MODBUS you ain't got nuthin' for time tags.

Anyway, I may be wrong about all of that--but that's my recollection of OPC versus MODBUS. And, hiring an experienced control system integrator that has worked with GE HMIs before, and Mark VIe, will put you that much closer to your goal of painless implementation (though GE can ALWAYS be counted on to throw a monkey wrench in the works with some perversion of a change that is undocumented (OH--sorry! all changes by GE are undocumented...!)).

Food for thought, and if we're lucky Faustojc or Demigrog will provide a few more details--correcting me if I'm wrong.
 
It is somewhat easy to set up an Mark VIe HMI to communicate via Modbus to the Honeywell HMI. The diagnostic tools on the Mark VIe HMI are MUCH better than the diagnostic tools on the PSCA or the controller. Additionally, you don't have to muck with the controller. You have to know a little bit on what your are doing with the Mark VIe HMI, but here I think the manual is someone sufficient.

However, back to your original question. 'Pinging' is ICMP based and really doesn't allow us to test if a particular TCP port is open. There are some tools out there to let you test if certain TCP ports are open, and that is what we need for Modbus communication. The firewall will have to have TCP port 502 (or 501 or whatever you configure) open so that both HMIs can talk back and forth. This is more of an IT question, but you may be able to get away with outbound only port 502 traffic if the Modbus connection is initiated from the inside...i.e. the Modbus slave is on the inside. However, you would need to test that to make sure.
 
There are several Modbus simulator packages available.

WinTECH has both a master and slave called ModScan and ModSim: http://win-tech.com/

Simply Modbus also makes both master and slave simulators: http://www.simplymodbus.ca/

Witte Software also has both, with Modbus Poll and Modbus Slave: https://www.modbustools.com/download.html

All of the above are paid software, but have demo versions available that should be sufficient to confirm that the connection succeeds.
Has anyone in the power industry used Modbus on Linux operating systems? I am taking a stab at it and it has not been easy.
In the old msdos MKV <i> modbus was an executible that ran as a service and as long as your comms configuration and data points matched at both ends, everything worked just fine. However, I have no idea how Linux works.
 
You might have better luck with this query if you open a new thread with an appropriate Subject relating MODBUS and Linux usage. If your specific interest is Mark* V <I> operator interface running IDOS with MSDOS scheduled as a task (IDOS is the GE proprietary multi-tasking system used on <I> operator interfaces for Mark* V turbine control panels) you should also state that. GE Salem have used various and sundry different methods for MODBUS communications at different times in the Mark* product life (proprietary executables; CIMPLICITY functions; WorkstationST (a GE proprietary background service); and so on and so forth--consistently inconsistent as many have said about GE Salem's turbine control systems and operator intefaces/HMIs) so I don't know if you have something particular in mind with GE systems or just power generation in general.

If I recall correctly, the Siemens Txx-3000, or whatever it's called, uses Linux on it's operator interface/HMI servers--but that's been almost a decade back now in my career. I'm sure MODBUS on Linux has been implemented MANY times, and probably in the power industry as well if only for data-capture from various equipment/controllers.

But, again try opening a new thread on Control.com and use an appropriate subject as click-bait and be as specific as you can about your intentions and the systems you intend to work with--and you'll probably at least more responses and maybe even more concise responses.
 
Thank you for your reply. I am not trying to get a MKV <i> going. Those days are behind me. I'm just working on a small project in my home to log energy use, etc... Long retired and now with nothing to do. I understood the MKV <i> use of modbus, but cant quite figure out how to do it with Linux. There are modbus packages/license I can buy, but they are all using windows. not my cup of tea. I just wish I could find someone else's example to see how they did it.

Thanks!
 
I still recommend opening a separate thread. There are a couple/three really knowledgeable MODBUS people on Control.com. I also think there is (or was) a MODBUS forum associated with Control.com. Perhaps David_2 can tell us.

MODBUS only caused me grief so I tried to avoid it if possible. It’s slow and doesn’t do time stamps—both real detractors for turbine operation and troubleshooting.

Good luck! (GE Salem was headed down the agnostic OS path at one time; owners were threatening not to buy GE turbines because the HMIs ram MS-Windows. The newest HMI networks run Linux and MS-Windows Virtual Machines on ThinClients—and they’re a mess, or at least they were, and GESalem wasn’t supporting them—even when they were less that two hours away.)
 
Out of curiosity, what's the problem you're trying to solve running Modbus on a Linus box?

I have to ask because there are 100's of thousands of HMI or SCADA apps running on Windows boxes that execute Modbus functions and equally as many, if not more that do so using a Modbus driver in OPC.

The listing of links to commonly used Modbus master/clients are all Windows implementations.

The tasks involved in configuring or programming Modbus, things like serial or ethernet communications setup, determining which registers to poll, correctly interpreting the data on the master/client end will be common tasks whether those tasks are implemented on a Windows box or a Linux box.

that ran as a service as long as your comms configuration and data points matched at both ends
Some Modbus apps run as an application in Windows (like those with the links) which presents an issue when the power drops out and comes back on - will the app restart automatically? Modbus running as a service in Windows largely solves that problem.

But the comms config and matching data points status has to be true regardless of which operating system you're working with.
 
The Modbus organization hosts a directory of its members at https://modbus.org/companies.php
You can search the list for linux.

The members list is maybe 1/1,000th of the commercial Modbus implementations out there, so do not consider it a comprehensive list, by any means. Google is your friend for the other 99% of Modbus vendors.
 
Alternatives:
1. If you're a programmer, then there's the Arduino line of low-cost processors with a recently introduced Arduino PLC that might have Modbus functionality (don't have to use the I/O). Then there are varieties like Raspberry Pi and whatnot that might have Modbus functionality. Others can augment this option, because I've paid close to zero attention to it; in fact I had to check how to spell Arduino.

2. Most HMI's are a Modbus Master/client. If you want/need an operator interface maybe an HMI would do the trick, directly fetching the data and displaying it for you.
 
Top