QUOTE (JesperMP @ Jun 21 2009, 08:01 AM)
You get my vote for that it is not spam.
I am interested in how it goes.
It looks slightly intimidating to my opinion. Is the server programming entirely in C or C++ ? Is there no graphical IDE ?
Maybe it is not so difficult for a beginner if there are simple templates to start with.
Apart from Qt, what software tools do you use yourself ?
How does web clients update ?
As far as I have seen with other Web-server solutions, they use a special Java component to achieve fast updates of the Browser HMI.
No graphical IDE as such unless you use one of the common "forms builders" out there which gives you template code, but again, not the typical editting environment that you are probably used to. It's one of the biggest problems with that particular HMI. It's more like a specialized version of say the built-in forms system that you get with all major IDE's such as Netbeans, Eclipse, Visual Studio, etc.
Java is NOT per se necessary to achieve fast updates. That's a bit of a myth. But if you were to do true browser-based HMI's (with Javascript), there are some problems to overcome:
1. How to connect the HMI to the data, with real time updating. The problem here is that a web browser is traditionally a "pull" system...the browser side initiates actions, while what one would desire is to "push" data. The solution is in the "comet" protocol. Essentially the web browser opens a data update request to the server. The server in turn responds as-needed with updated data. Then the browser immediately pushes out another request. If you overlap them, you can even defeat any round-trip time delay issues.
2. A related problem...how to get an HMI to pull data from non-HTTP sources. Alas this one is fairly hard to solve. There are ways to "jail break" a browser by the use of plugins but there is no general solution to make a browser for instance do "Modbus/TCP" without involving a server of some sort. Since many modern HMI's are in fact client/server based, this appears to be a non-issue.
3. Security. This is another tough nut to crack. The simplest backend would be say an OPC server (OPC/DA). The problem here is that if you made this sort of server accessible in a "raw" form via the web browser, then it wouldn't be long before someone would figure out that you can read/write ANY data to the backend with no security. So clearly the security aspect of things has to be handled at the server end. Similarly, protection has to be built in to prevent someone from simply doing a "Save As..." and then passing a secure web page to a non-secure browser. This is simple to do with session keys and such at the server level, but again, must be implemented properly.
4. The speed question. I think this one is much less of an issue than folks make it out to be. Here are some demos to show what I mean:
http://maps.google.com/http://www.simile-widgets.org/http://demos.dojotoolkit.org/demos/cropper/Note that 2 or 3 years ago, the speed question was a big issue. And development was just plain horrible in the Javascript world. However, times have changed. Very modern libraries such as
http://www.dojotoolkit.org/ have come into play and are getting better all the time. They are also being highly compressed and modular to make them very light weight so that you don't spend a considerable amount of time downloading unnecessary overhead code.
Most browsers are now starting to support very high end graphical features such as SVG and Canvas. This is not a prerequisite to high quality HMI's (especially with a library like Dojo) but it certainly doesn't hurt!
The final problem of course is that like it or not, in the end, Javascript really isn't all that fast since it is interpreted. However, even that issue has very recently in the last year or two become a moot point. The key to the solution is something called a tracing compiler:
http://www.usenix.org/events/vee06/full_papers/p144-gal.pdfhttp://andreasgal.com/2008/08/22/tracing-the-web/The amazing thing about this style of compiler is that it can achieve close to 90% of the speed of the Sun Java 5/6 compiler but does so with a fraction of the code size, memory footprint, and coding time. Essentially the entire compiler can be realistically built in about a year as a graduate project. Fortunately, nobody has to do this. Firefox 3.5 (going to be released any day now), Safari, Chrome, and I think even Opera all have such compilers today. The performance that these javascript compilers bring to the table is nothing short of amazing.
That leaves just one final sticky issue. None of these features are available in Internet Explorer. So if you want across-the-board support for these kinds of features, you have to make it browser-specific, or at least browser-antagonistic towards one particular 90 pound weakling in the browser wars.
Items 1-3 can be neatly sidestepped using Java outright since it can directly handle all 3 issues even in a serverless scenario. So to be fair, it's not that Java is a prerequisite. It just makes life easier in many cases.
Now here's an experience where I actually implemented such a monster. In the last plant I worked at, it was a GE Fanuc Proficy Cimplicity house. We had extensive experience with it all the way around. We used the web-based version a lot in many places where we needed a "temporary" HMI (such as giving supervisors an "HMI" on an as-needed basis to monitor/control plant-floor activities). The actual implementation is a bit long in the tooth but works like this. It runs a captive version of the standard Cimplicity HMI on a server. The captive version writes to a screen buffer rather than to the normal desktop. Then the server portion does screen scraping and sends the updates to a special Java applet. It works almost identical to RDP or VNC in practice.
Even more interestingly, Neoware was a thin client manufacturer. Before they were absorbed by HP, version 4 of their software supported plugins, of which one such plugin was Firefox 2 and Java. We actually loaded up Firefox/Java and pointed it to the Cimplicity web server, which produced a "serverless thin client"...the thin client was directly running the Java version of Cimplicity off the Cimplicity server without a "thin client server" involved in the middle. It ran alongside a traditional thin client operator station.
In terms of stability, both systems were rock steady. There were three limitations on the web-client version. First, the Cimplicity Java implementation is getting very long in the tooth (still almost identical from version 4 and Cimplicity is now at version 8). Many ActiveX plugins just don't work quite right. Second, we never quite got "kiosk" mode to work in Firefox so we could never quite get rid of the very obvious Firefox menu bar at the top of the screen. Third, and this was our setup,
