Wonderware, Ethernet, and all things complicated

[JRoss 84]

The Scenario I have a customer who wants a vision system installed that will communicate with WonderWare InTouch and InSql for operator interface and historical data collection. The camera is the IVC-3D Smart Camera from SICK, Inc. It's a really neat product, allowing for three-dimensional inspection. It has Ethernet communication built in, using the basic TCP/IP protocol. According to the Wonderware rep with whom I spoke, Wonderware products use a protocol called SweetLink, and any connecting devices must either speak that protocol or use a translator. One "translation" method is using ActiveX controls, as Wonderware is an ActiveX container. Fortunately, the software programming suite for the IVC-3D, called IVC Studio, has ActiveX control built-in, so that can be taken care of with a minimum of difficulty. However, it will require that my customer installs IVC Studio on all his terminals. He is not opposed to this, but it seems to me there should be an easier way. The Question First, let me state that I am no Ethernet expert, just an informed user. That being said, it is my understanding that TCP/IP is a base protocol, and other protocols like SweetLink, Ethernet/IP, etc. run on top of that. If that is not the case, we're done here, you can tell me, and I'll go on my merry ActiveX way. However, if that is correct here's what I want to know. When I set the IVC-3D to send data via Ethernet, I identify a string, a destination IP address, and a destination port. That's it. For this reason, SICK calls it "Ethernet Raw". Is there any reason I cannot simply format my raw data string to match what would be sent by a SweetLink device? In other words, take my data and add any necessary header and footer information? I've heard of this being done in serial communications, and would like to know if the concept is transferable. If this is possible, then it would be neat to use for other data connections, specifically the AB stuff that I'm constantly banging my nose against. I have another customer that used the IVC-3D and wanted to talk to an AB PLC. We ended up using the camera's digital I/O since we couldn't talk Ethernet/IP. It was an acceptable alternative, just not what the customer had in mind. If you got this far, thanks for sticking with me!

[Camel 1]

This help any? Or This? TCP/IP Have you used the Rapid Protocol Modeler Toolkit that comes with wonderware? I haven't, but the name sounds promising......

[rpraveenkum 5]

Ethernet layer Edited 25 Jan 2007 by rpraveenkum

[GerryM 2]

Yes, you should be able to if you know the Sweetlink protocol. I'd help further but I've never heard of Sweetlink.

[GerryM 2]

That's funny! I've never heard of SuiteLink either, but I haven't used a vision camera in years either.

[wildswing 0]

SuiteLink is WW's beefed up version of DDE. Wonderware Intouch can also speak DDE.

[JRoss 84]

So where would I go to find out about the protocol? I'm in brand-new territory here with Ethernet, so any links, etc. would be appreciated. Thanks!

[paulengr 44]

That's a nightmare. "Suitelink" is basically a beefed up DDE. It still has the usual attributes of DDE at least as of version 6/7 of Intouch (occasionally just simply locking up for no reason and stops communicating). Your camera is just flat out TCP/IP. It doesn't use any of the higher level features, but you can easily connect to/from it using ordinary "telnet". ...which means that it can interface to just about anything. The issue is that Wonderware basically doesn't want to talk to anything...highly proprietary. It is even worse than the darned Microsoft "standards? We don't need no stinking standards! We are the standard!! Or we'll sell you one for a mere $499.95, plus annual license fees." If it is possible to write VBA code within Wonderware (it wasn't the last time I used it), then you COULD use the ActiveX sockets. Otherwise, you are stuck writing a little VB helper application compiled as an OCX that will export the appropriate stuff for Wonderware to use. You can't get to it from the SQL side either. Wonderware calls "InSQL" a "SQL Server compatible" system. Far from it! It is merely a totally alien database system running along side the real SQL server and hijacking SQL calls to make it appear SQL-like.

[JRoss 84]

Nice. So because I'm working with Wonderware, it looks like a no-can-do. Out of curiosity, how about Ethernet/IP (aka CIP)? Let me beat the horse a bit longer. I was told by a technical rep that Wonderware is an ActiveX "container", and can therefore handle tags built around ActiveX components on other products. I'm understanding you to be saying that isn't the case. Perhaps the newer versions can, and the older versions can't? If that's so, I'm still not out of the dark, as the customer is on version 7.1. So, about the "VB helper application compiled as an OCX"... You wouldn't happen to have a sample I could have do you? I haven't done any VB programming, just VBA, and certainly am not up to that level. Thanks!

[Camel 1]

Don't give up that easy. You should really check out Wonderwares Rapid Protocol Modeler Toolkit. It looks like it will do exactly what you want.

[paulengr 44]

Edited 2 Feb 2007 by paulengr

[JRoss 84]

Thanks Paul. You can bet I'll refer to this when/if we get the job. And in the future when (not if) something similar comes along.

[JRoss 84]

krk, how simple are we talking? All I need to do is send seven pieces of numeric data (floating point, preferably) to InTouch four times every minute. Thanks.

[Nathan 7]

I got quite a kick out of this. Great points! What charting library did you end up using?

[JRoss 84]

Thanks to everybody for their input. At this point, the contract has not been awarded. The project moved from plant level to the companies New Technologies Group because of the possibility of using the system for multiple plants. Last time I checked, they had yet to assign a corporate engineer. Ah the cogs of the corporate machine. As a result I put my "discovery" phase on hold to deal with more immediate matters. I'll be sure to add more to this thread if we get the contract! Edit: I haven't thought about this issue for a while, and doing so jogged my memory. About six weeks ago, I found out that SICK is in the process of adding the Ethernet/IP protocol to their smart cameras. The functionality is in the current demo version of the firmware, or so I've been told. I haven't had a chance to play with it yet. The plant uses all A-B equipment, so I should be able to send the data to the machine's PLC and pull the data into Wonderware from there. Edited 4 Apr 2007 by JRoss

[paulengr 44]

You would be very surprised, or perhaps not. I came up with first one alternative and then a second that I implemented later. The first alternative was to simply create the whole thing using a JSP, a backing bean, and the CEWOLF library interface to JFreeChart. The code in the HMI consisted of summoning Internet Explorer as the sole ActiveX object and feeding changes to the server via "GET" type HTTP (change the URL). It worked, but it made for lots of hidden code over on the server, and...it's downright ugly and a very dirty hack. The advantage here is beautiful charts, on par or usually better than Excel. Version 2 is slightly better, and the charts have improved. Speed is improved and server load has dropped down to only raw SQL data. It is also a dirty hack. Suck the data in via VBA and emit HTML into a text file on the local hard drive. Then point Internet Explorer at that file. The actual chart engine is the one in Dojo. I put the Dojo library on the server just to make this something less than the serious hack that it is.

[Nathan 7]

Paul, JFreeChart is THE BOMB! That's what we use behind the scenes in FactoryPMI (with functional additions/modifications of course). Am I correct in assuming that CEWOLF was feeding you static charts so all the knarliness you had to write was for updates? Seems like CEWOLF could do the rest of what you mentioned. I love AJAX (for using, not developing). I wouldn't expect Dojo to be quite as cool as JFree, but how is it? Can the user zoom, scroll, get point values, export to Excel, etc? Those are the kinds of things that I like about using a program/applet that gets to keep running like Java. Similarly, I bet a killer job could be done in Flash if anyone bothered. In any event, I used to write PHP programs using JPGraph (Kudos) or ASP scripts using some commercial version (doesn't come to mind). I don't miss the whole scrolling/rescalling via HTTP GET/POSTs. It did clever mouseovers with HTML image maps - very creative, but I usually disabled it because it was too slow/clunky with very many data points. Good that the chart rendering is done on the client machine and that the server is only passing raw data! Edited 16 Apr 2007 by Nathan

[paulengr 44]

There are plusses and minuses to using Dojo. First, the obvious. We're talking Javascript here. The new chart library is even nicer than Jfreechart in many ways. And it is really, really fast since you're not pushing bit maps around but rendering directly in the browser. Dojo and the chart library are also directly accessible from Netbeans so if that's your development environment, you can write everything in the appropriate schizophrenic (Javascript/JSP/Java) language very easily. Inevitably, the problem is always in the data input/output area. Fortunately, dojo has implemented xmlhttprequest, iframe requests, etc. in spades. It is very easy to do data transfers with it, even dynamic ones. Since it is not based on the server, you don't have direct access to JDBC. This can be a plus depending on how security paranoid you are. Instead of just redrawing the whole chart, when the browser scrolls or zooms, it can simply request the updated data via xmlhttprequest and the chart gets updated dynamically. Point values are easy to get too. The one area that I haven't tried to implement is in the FILE I/O area. Since you're in a browser, this could potentially be a pain in the rear. Each of the 3 major browsers (Opera, Internet Explorer, Firefox) do allow you to save or load files as long as you go through the appropriate standard interface which allows the user to control what you are doing, but each browser is different in how this is implemented. Since you mentioned Excel, I'm not 100% sure how to put it into an Excel native file format. The portal that we use right now is GE Fanuc's Real Time Information Portal which also happens to be essentially 100% Java applet. The way that it gets around the Excel file format problem is by limiting the user to saving files in PDF, PNG, or CSV (comma separated value) formats, and CSV can be imported into Excel. As for flash...the latest incarnations are basically Javascript with a different BOM/AOM/DOM (whatever you call the object model). I hear the latest versions are much better but at least the older versions were pretty limited once you try to implement code of any decent proportion. BTW...I have been very impressed with FactoryPMI overall. It took me a little bit to grok the idea of using SQL as a general database for everything in the HMI but it definitely seems to work quite well. I'd go ahead and roll it out in the plant but I've got the old chicken-and-egg problem. We already have an extensively developed GE Cimplicity PE system in place. Conversion costs would just about equal the annual licensing fees we pay to GE. That's the hump...once you have a system in place and fairly mature, how to abort and switch. If someone were to write something to read GE's LISP-like file format for their graphics stuff and make importing fairly smooth, it might make the transition to something else a lot easier. Out of the 4 of us that made the decision to stay with GE at the last major version upgrade, 2 of us were all for dumping it and going for RS-View. If I knew about FactoryPMI at the time, I would have considered that one even more.

[Nathan 7]

I'm glad you like FactoryPMI - it's a cool package. We're working on SQLTags now, a static-schema "tag database-like" approach where we'll do a lot more legwork in terms of database layout. It will make design simpler and greatly enhance performance. After that and a few more components the plan is to create a vector based model for primitive objects (on which EVERY other HMI is based). I recently saw a demo where the company's software package opened up several different HMI projects: A Wonderware one, the RSView demo with the blimp and others, Cimplicity, and a few others including an SVG file. Their program parsed the projects into an intermediate XML format, then allowed them to "import" it into a Citect project. Further, they could define modifications that would recognize patterns to import aspects of the project differently. What amazed me was how good of a job it did. All the HMIs objects could be broken down to a limited number of fundamental shapes - most didn't even support bezier curves. The program would show the scripts for "Animation" and "Expressions", both very user parsable. The other thing that shocked me was how simple the data was represented for their tag databases". Most had around 5 tables - one for each data type, each with a ton of columns that represented properties. Each tag of a given type was a row. Not exactly extensible.