Hi all,

I am new to posting information on these type website although I learn from them constantly.

We build industrial control panels and are self taught for all programming that has been necessary (Very capable thinkers but not traditionally trained). I am new to communications and am having a hard time drawing a complete picture of internet protocols.

I have a Modbus network between motor VFD's, PLC's, and HMI's that have a few values I would like to display and control. I would like this to be accessible by any standard web browser. My HMI has the ability to communicate through Modbus TCP/IP. Through researching sites I have come to the conclusion that TCP/IP is not much more than a method of establishing a communication handshake and method of sorting the bytes of information.

There are some off the shelf products that have "built in web servers" that will take my Modbus network and provide an IP address to view and control values but are usually expensive. I am having a hard time understanding why I need such a product if I have a component (HMI) that is already TCP/IP ready. Can someone please help me understand why I cannot access my HMI directly since it has an IP address and is TCP/IP ready. Suggestions of hardware and software to make this happen (if necessary) would be appreciated. Thanks

 

You asked for an explanation and a solution. I have both here for you. I will give you a brief explanation of the technology. If you want more details then let me know and I can expand on it.

TCP/IP is concerned with getting the bits and bytes that make up the data from one place to another. It doesn't concern itself with what the data actually *means*. Modbus/TCP and HTTP (the web protocol) are application level protocols that are concerned with what the data actually means. They use TCP/IP to get their data from place to place.

If you send an HTTP request from a web browser to a Modbus/TCP server (slave), the Modbus software will look at the message and say "that doesn't look at all like a Modbus message, it must just be some bad data", and reject it. The same thing will happen if you send a Modbus request to an HTTP server (web server).

You *could* have both a Modbus/TCP server and web server built into the same device. You just have to make sure the Modbus messages get sent to the Modbus server, and the HTTP messages get sent to the web server. TCP/IP does this by what are called "ports". A TCP/IP "port" is just a code number that is sent with the message to tell the receiver what sort of message it is. Modbus/TCP usually has a port number of 502, and HTTP usually has a port number of 80. So, the Modbus/TCP server will say "give me all the messages sent to port 502", and the HTTP server will say "give me all the messages sent to port 80". However, you could use any port number at all (e.g. you could use 8080 for the web server) provided that both ends of the communications know what number to use.

I happen to have a free and open source software project that does web based HMI. You can download it from: "http://sourceforge.net/projects/mblogic/". The web site for the project is at: "http://mblogic.sourceforge.net/".

I am working on the final release testing of a new version that makes creating the HMI web pages a lot easier. That should be out within a couple of days. So far as creating HMI web pages is concerned, it's quite a major change so check back again later if you want to see what is happening.

The MBTools package includes two programs called "HMIServer". There is one version that acts as a Modbus/TCP client (master), and one that acts as a Modbus/TCP server (slave). The web server is built in.

The MBLogic package has a complete soft logic system, but you can just use the HMI part of it if that is all you want. It allows multiple Modbus/TCP client (master) connections to multiple devices, so if you want a single HMI web page to summarise data from multiple PLCs when those PLCs are all servers (slaves), then you would want this rather than HMIServer. Both MBLogic and HMIServer have the identical web based HMI; HMIServer just offers it in a simpler form.

The MBLogic-All package simply bundles everything together so you can download it all from the main download page instead of selecting individual files.

All packages run on both Linux and MS Windows. You can run them on a PC, or I know of some users who are running them on off the shelf low cost embedded hardware using Linux. The hardware requirements are fairly small, so you don't need much to run them on if you are just using the HMI features. You can also simply run the HMI server on the same computer that is running the web browser.

Here's a web page that gives you a brief overview of the HMI, along with some screen shots:
"http://mblogic.sourceforge.net/mbhmi/mbhmiintro.html"


How a web based HMI works is more or less like this:

1) First you need a web server to serve up the web pages. For MBLogic/HMIServer that is built into the main program, so there's no need for a separate server program to do that. Some other systems require you to install MS IIS server, which can be quite difficult and expensive.

2) Your web browser asks the web server to give it the HMI web page. That web page will typically consist of a number of files (HTML, graphics, Javascript, etc.).

3) Your web browser then receives the page, interprets it, and displays it to you.

4) It also runs any embedded Javascript code. Javascript by the way is not related to Java. Those are two completely different programming languages. Javascript is the language built into web browsers.

5) At this point what happens next depends on whose system you are using. I use the features built right into most modern web browsers, while some others use Java or MS ActiveX programs ("plug-ins") which they download to run on your computer. The following assumes you are using MBLogic/HMIServer.

6) The Javascript in the web page then creates a request message and sends it back to the HMI server. The HMI server interprets the message and turns it into a series of Modbus/TCP messages which it uses to read data from and write data to the PLC.

If you are using a Modbus/TCP server (slave) version of the HMI server with the PLC as the client (master), then the HMI server is just getting the data from its own data table. The PLC in that case is responsible for reading and writing to the HMI server (using Modbus/TCP).

7) The HMI server then formats a response message and sends it to the web browser.

8) The web browser receives the message and uses the data to update its display.

9) The web browser waits some specified period of time and sends a new request and the cycle repeats from step #6.


There's a lot more detail involved, but that's the basics. I have used what is called "AJAX" methods (Asynchronous Javascript And XML). For graphics I used SVG. The communications cycle all happens in the background, so you see data changing on the screen without the web page itself reloading.

You mentioned that the proprietary systems that you looked at were quite expensive. Most of these use Java or MS ActiveX programs that get downloaded and run on your PC. They're only sort-of web based, in that their output appears in the same window as your web browser. They're not really part of the web page though.

If you want to talk some more about this, let me know and I will be happy to answer any questions.

 

You need Modbus TCP/IP capabilities in both ends (master and slaves) to establish a connection. Web server enabled products are expensive and not compatible with Modbus (they use http protocol).
If you have a Modbus TCP/IP HMI you can take two ways for a solution:

1.- Buy the MB TCP protocol cards (modules) for all your slaves (VFDs, PLCs, etc.)

2.- If your slaves have MB RTU (serial) then connect them through a bridge (serial-to-ethernet) to your HMI

This last is often the cheapest way because MB RTU is included in most industrial devices.

 

It is funny you responded as about a month ago I stumbled onto your software while trying to accomplish this on my own. I did not have much luck implementing your software or even getting it started. I really appreciate the response and it is helping a lot as for the understanding. I would definitely like to discuss your software in detail and get it to work for us. Feel free to contact me either in this post or by email Travis [at] Com-Pac.net. I was wondering if your software will work on Mac's. We all use apple here but do have some PC's for programs that only run on PC's. Thanks again and I will try to give your software another go to see if I can get it to work. I will download it again and see if I can get it started.

 

As M. Griffin already mentioned TCP/IP is a "transport protocol" that gets data from A to B.
See:
http://en.wikipedia.org/wiki/OSI_model

HTTP and Modbus/TCP are application layer protocols according to the OSI model.

We also provide an open source project that implements HMI and data acquisition with Modbus/TCP for example.
See:
http://pvbrowser.org

John Correa is using our project and might also give a comment to pvbrowser.

We use separate programs for data acquisition and HMI server. The data acquisition will run cyclically and write the process data into a "shared memory" and wait on a "mailbox" for outputs. Thus you get the following scheme.
http://pvbrowser.de/pvbrowser/pic/prinzip.png

@M. Griffin:
Please look at this scheme.
It might be interesting also for you
because in your Ajax based solution this could also be used. Thus it might be possible to cooperate in data acquisition even if we do it different in the HMI.

If somebody wants to talk about
http://pvbrowser.org
please come to
http://tech.groups.yahoo.com/group/pvbrowser/

@Travis:
pvbrowser also runs on OS-X because it is based on Qt.

 

I don't have a Mac, so I can't test it myself. I can say that it *ought* to work as is, and I have heard from another user that he has successfully run the server software on a Mac.

When you go to the Sourceforge web site, it checks the browser string to check what OS you are using and then displays the package that matches it. That is a Sourceforge feature which I don't have any control over. So, if you are using an MS Windows computer it shows you the MS Windows default package, and if you are using Linux it shows you the Linux default package. I don't have an OS/X version (since I don't have Mac hardware to test it on) so I don't know what it will show you if you have a Mac.

As I mentioned above, one user did tell me he was running it on a Mac. I just had a quick look through my e-mails and I can't find the discussion, but I believe he originally had a problem because he used a Windows computer to download the package and he got the MS Windows version (zip file). He then tried the Linux version (tar.gz file) and then everything worked fine.

Mac OS/X is basically a nicely polished Unix system, so there's not much difference from Linux when it comes to running server software and web interfaces (which is what this software does).

I have tested the client (browser) software on the MS Windows version of Apple Safari web browser, and it did work there. I also regularly test on the Linux version of Google Chrome, which (like Safari) is a WebKit browser (and I also test on Opera). The client (web page) is intended to work on a Mac in Safari, and if for some reason it doesn't then I would like to fix that (although I don't have a Mac for testing). One of the use cases that I planned for was people in an office wanting to view web pages (of things like production status or summaries) on their Mac.


As far as creating your own HMI application is concerned, up until last weekend you would have had to know at least something about creating a web page. The new release makes that a lot easier now, as the new documentation explains how to use Inkscape to draw the graphical part of the system, and the sample web pages are set up as ready to use templates. Up until now people have been making their own HMI applications with it using conventional web development techniques. The latest work I have been doing has concentrated on making that easier, and I have more ease of development improvements planned.

I will contact you off list so we can turn around the discussion faster than this lists progresses, and then update the thread here for the benefit of others when we're done. The installation documentation includes step by step instructions for installing and verifying the installation, and also how to start the demo which comes with it. I will tell you what information to send to me to let me know what is going on. Of course if you would rather discuss it here, that's fine with me. There are also support forums on the project site on Sourceforge, and I check those and answer questions there as well.

 

In reply to pvbrowser: Your project is addressing a somewhat different market than the one I am aiming at. I have an HMI, but I'm not trying to produce a custom SCADA system (like your project) or a data historian (like Plantstreamer). Instead MBLogic is meant to be an easy to use automation platform for factory automation of small to medium size systems and also in building automation systems.

I needed a simple HMI system to go with this, and a web based system seemed to have a lot of technical advantages from the user perspective as well as being more practical to develop. I offer the HMI system in a stand alone form because I have a policy of splitting the tools up into stand alone components in cases where those might be useful to people. That's where HMIServer comes from.

HMIServer has been surprisingly (to me) popular as an HMI for PLCs (and other devices) and there are people using it in and extending it beyond that for applications which I hadn't anticipated. However, I don't have plans of my own to turn it into a SCADA system proper. I do plan to continue to support it though, as it seems to be meeting a genuine need.

If you happen to like the SVG clip art that I've created (push buttons, pilot lights, etc.), then you're welcome to use them. We can discuss how they could be modified to make the easier for you to use. I found that I had to embed various definitions and Javascript calls in them to make them easy to integrate in the "system" that I've created. I auto-generate the final files using scripts (there are hundreds of files), so I could probably generate versions that are directly useful for you.

What I see as an area of cooperation with you (as well as anyone else who is interested) is creating a base library of SVG clip art that could be used in different applications. There is more work in that then may appear at first hand, because it involves things such as agreeing on standards for appearance, relative size, gradient definition names, lighting angles, shadows, etc.

What I would suggest is that you do first is download the new packages from MBLogic and have a look at the SVG files (they're in a archive called "hmibuilder" inside the main package) and maybe try a few experiments. Then we can talk about it. You can get my direct contact information through the source code headers (I don't publish it directly because I don't want to get spammed to death).

Can you use a complete Inkscape SVG drawing directly, or do you have to use SVG in individual pieces? I didn't know I could use Inkscape for this until late last year when someone contacted me about a project he was working on. He had drawn some very nice process drawings for a customer demo and planned on using them as backgrounds (he was using Inkscape because that just happens to be the drawing program he uses). I looked at them closely and realised that he could just animate the original drawings rather than using them as backgrounds. That's what has sparked my current efforts in this area. I just take a completed drawing and stick it right in the web page. The Javascript can grab parts of the drawing use the "id" and change colours, rotate switches, etc. For a lot of applications the whole drawing would just be bits of clip art stuck on the same drawing, which is where the clip are library comes in.

Also, I've published the protocol that my web based system uses (see the thread on "Cascadas Protocol Specification"). I worked on this jointly with some other parties who wanted it for their own applications. If you implemented the server protocol for this in your own system you could use the existing SVG and Javascript libraries as is directly (these are system independent). This wouldn't replace your existing QT system, but if you wanted a web based system to supplement it (for example, as part of a management reporting system) it would give you an off the shelf solution. The same goes for anyone else who is interested.

The next step in this is to write a program that automatically puts the drawing into the web page template and creates the configuration data and animation scripting calls based on menu driven input. That will expect certain naming conventions for data and libraries, which is why consistency matters.

However as I've said, have a look at what I've got, try a few experiments of your own, and then let me know what you think. I have a few more features (SVG and Javascript) that I'm working on but they won't change the basic approach that I'm using now.

 

> Suggestions of hardware and software to make this happen (if necessary) would be appreciated. <

I have one more suggestion for you.

We have just released another version of CSWorks - free web-based HMI software framework for Microsoft .NET/Silverlight. Among other things, it can communicate to a Modbus device (provided that you have an OPC server for it), and the client runs perfectly on Mac.

Too many features to list here, see http://www.controlsystemworks.com/ProductFeatures.aspx for highlights.

But you will have to build your HMI screens using Microsoft Visual Studio or Expression, and these are not traditional tools for HMI app developers. There will be a learning curve.

Product setup doesn't require any special knolwledge and runs on any XP/Vista/W7/W2K3/W2K8 machine with IIS, .NET 3.5, ASP.NET and Silverlight 3.0 installed.

Drop us a line at support@[csworks website above] if you need help with the product.

 

>If you want to talk some more about this, let me know and I will be happy to answer any questions.<

Hi! I donwloaded your code but I can't find the js code to access to the ModBus Slave (I want a Master HMI).

I'm developer, maybe I can help you.

I understand you want use AJAX to ask your webserver and then it ask to the slave modbus.

Please, email me at [email protected] and we can talk

And, for the record, I'm Argentinian, my English is so bad