Should I use the same machine for both FactoryPMI and FactorySQL?
What should I be concerned about when planing a server?
Should I use the same machine for both FactoryPMI and FactorySQL?
Definitely run tests for the size of your “enterprise” to determine if a single standalone server is sufficient to run FactorySQL, FactoryPMI, and the database for that matter. In our experience, the answer is typically “yes”, you can use the same machine to run FactorySQL, FactoryPMI, and the SQL database.
When planning a server, you’re faced with the same considerations as you would have for a web/database/application server. CPU speed matters, but isn’t an end all factor. Always have enough RAM for your server. Consider fast hard drives and RAID arrays for redundancy and performance as appropriate. DEFINITELY have a back up plan!
The advantage of a database centric model is that you have ONE DATABASE to backup. It’s that simple. Don’t allow yourself to lose that one database.
“Beefy” servers with good warranties can be had from Dell in the sub $3500 price range that are overkill for most reasonable sized projects. I’d recommend testing the software out on a new $800 XP pro machine. I think you’ll be pleasantly surprised with the performance. I recommend at least a gig of RAM, not because you need it, but just to make sure you have more than enough.
Since this thread is over a year old, I wanted to know if what Nathan states above is still pretty reasonable. My configuration will look like this: One PC acting as the “server”, running FactorySQL, FactoryPMI, and MSSQL 2005, and two PCs running only the FactoryPMI clients.
I would imagine the client PCs can be pretty average (standard desktop PCs that you see in any business environment), but what about the other PC?
The server PC’s stats depend completely on the size of the system you’re putting together. This means: how much history you’re logging, how fast, how many tags, and how many clients. You’ve told us that you have 2 clients, so now we just need to fill in the rest of the parameters.
A good bet for most average sized projects is an entry-level server computer or a nice desktop/workstation computer, which should run you around $2-3k.
1-2 CPUs, 1-2GB RAM, and RAID hard drives are nice.
An “average sized project” is one with ranges like:
1k-15k tags (mixed realtime and history)
Logging in the 1sec+ range
These numbers are very rough.
Hope this helps,
One more thing - good idea resurrecting this thread, because SQLTags made us far more efficient in the realtime status/control arena, and as such, server PC load is greatly diminished for realtime/status tags.
I did some tests last night after converting most of my project to SQL tags, and the difference is huge. The screens are much closer to the real time status, and my remaining groups are used for what they should be used for instead of as a pass-through device for status values. Great work guys.
Also, my tests were done on a computer I threw together from parts (decent processor, fast hard drive, 2GB ram, XP Pro) and the results were very positive. I have about 1200 tags and 8 groups, which is probably on the low side of what you consider an average project, but then again I have the update rates set very low (200ms). Still, things looked pretty good.
You said the number of clients would affect the server load. Can you elaborate? When would I see a difference? Let’s say I put a couple of clients out on the floor, but then the customer goes nuts and installs it on 10 more desktops. Is that an issue?
Thanks! Glad its working well for you.
You shouldn’t notice any significant difference with 10 clients. It really depends on the load that each client is adding to the system. Note that this is one of the areas where SQLTags scales much, much better than our old paradigm. Suppose that you have 100 tags on a screen. With the old way, those 100 tags would poll for each client, making each client add lots of load to the database. Now, the database sees constant load no matter how many clients are running.
We are doing formal benchmarks soon, but informally we had 93 clients with 40 subscribed tags each running in our office with a desktop-class server, and things were running great. Stay tuned for formal benchmarks.
Additional clients should add minimal network traffic and a small amount of additional load to the FPMI gateway. They should not change database or OPC traffic.
The caveat is that you have a one “unit” cost for tags that are being used (think in terms of open screens). I’m pretty sure that a few clients with lots of big screens would be more intensive than many clients that have the same screen or two open.
As Carl said, “stay tuned for benchmarks”. We really don’t expect a “catch”. SQLTags seems to considerably increase performance.
Ok, another computer question. I realize that the clients can’t run on a handheld yet, but do you envision any problems with a tablet PC? I’m talking specifically about the new XT Tablet from Dell. It uses an XP version that is optomized for tablets, and my first guess is that it wouldn’t be an issue, but wanted to run it by you first.
As an aside, do you see any other handheld devices coming out in the near future that I could run my GUI on? I think my customers would be all over it if I could offer it to them.
As you suspected, the FactoryPMI client will run fine on windows XP tablet edition and windows XP embedded.
As for your aside, the crux of the issue is whether or not there is a full J2SE (NOT J2ME or J2EE) Java JVM that will run on the device. We are also waiting anxiously for the first handheld that will run a full J2SE, or, conversely, waiting for Sun to release a J2SE that will run on something like Windows CE.
Either the technology will catch up to us, or we will eventually create a “mobile” edition of FactoryPMI.
Another question: Has anyone tried launching a FactoryPMI client on something like a Wyse ThinClient? They come in a lot of flavors, even without an OS or hard drive. I have a need for a bunch of read-only GUIs (not even a keyboard), and it would be great to sprinkle some of these throughout the plant.
I use Wyse Thin Clients at work, although I haven’t dealt with many “flavors”. I suspect that they’d work fine, but don’t really get the benefit of the architecture. Think of them like hardware implementations of terminal services clients. They boot up a super-trim version of windows that has icons to remote desktop servers. They would be better to distribute a “heavy” app like an old stand alone HMI. Correct me if you have a hard drive-less version with a web browser and JRE installed - sounds possible…who knows how the 300mHz CPU would render graphs, though…
I wouldn’t use a Wyse Thin Client just to display an image because of the price. You could get “media adapters” to push a display over Ethernet. Taking it a step farther, we have an integrator who sets up >37" LCD TVs as “industrial Marquees”. He found that you really need a DVI/HDMI input to make them look sharp at that resolution. While they have Cat 5e/6 extenders for video of that quality, he found it most reasonable to throw a $300 computer as the “video driver”.
A cool idea would be to centrally control the screens that the different monitors display. It’d be pretty simple with SQLTags and a little scripting.
Thanks for the ideas. Yeah, my first choice would be not to have a PC out on the floor at all, and looked at video boosters from these guys: http://www.cablestogo.com/product.asp?cat%5Fid=503&sku=29559 . I’ll probably order one and see where it gets me.
I have seen tvs used as marquees too, but wouldn’t be appropriate in this app (too much hardware around for a clear line of sight). Industrial panel PCs are expensive and overkill. The particular screens that the operators would be looking at would definitely be lightweight (showing the current order, stuff like that) and would not involve graphing or charts.
So, one reason I considered the thin clients is that they don’t have a hard drive and are fanless (no moving parts) and I could throw them in existing enclosures (even din rail mount them). But if I can push the display over ethernet from the “clean room”, that would be even better. Have you used a particular media adapter with success?
Another PC question: If this project goes through, I’ll be doing a lot of queries on very large tables. I was looking at two PCs. One has an I7 processor (the Dell XPS line) , and I can add large amounts of additional memory. The other has a Xeon processor (the Dell Inspiron line) and tops out at 6gb ram. The two processors are very similar, and the main difference is that the Inspiron is geared more for server applications. I would be using Vista 64 bit Ultimate.
So, knowing that SQL Server allocates as much memory as it needs, is there any benefit of using something like the XPS with, say, 12gb ram, or is the 6gb Inspiron already overkill?