Nathan

I stand corrected. However, I have been charged > $100 for short serial cables with "secret" pinouts - mostly missing pins with a few switched. It's the kind of thing that leaves you bitter for a long time. Also - I said AB, but meant to refer to all the vendors out there who are producing new equipment and deliberately playing that game.

It's silly that modern PLCs don't support Ethernet or USB local configuration. This problem has existed for years and will probably continue into the foreseeable future. I think AB's planning on riding the custom cable cash cow as long as they can. We should collectively build a knowledge base for what converters/adapters work with which AB devices.

That's unfortunate, but probably true. I wouldn't conclude that as the general case, but I've heard that about Rockwell Software before. It's amazing how tight recent versions of RDP run. I've had positive experiences in a SEVERELY bandwidth constrained environment. Almost enough to convince those geeky shell based users I strongly second BobLfoot's advice on both posts - his experiences as an integrator getting remote access to customer sites sound nearly identical to mine. You really don't want to get billed for connecting and configuring time when a slick setup beforehand can greatly expedite remote troubleshooting. Too much is at stake. finfin - could you give more details about the RADES modem and RADKIT.

Paul's responses were solid with respect to running HMI/SCADA applications remotely. I think you have a few other things to consider based on your OP. 1. Having a technical Engineer/Integrator troubleshooting the process at home is more likely to require access to the PLC programming software than the HMI (which may or may not be working). 1a. A VPN connection would get the remote computer on the network. The host could run PLC programming (or any) software locally and connect to the process. 1b. Running remote control software to a PC that has the correct applications set up is also possible. PCAnywhere or Gotomypc are an option. If you have a network connection already (VPN) then you can have this service by running Remote Desktop, VNC, or Dameware. I prefer the latter options for reasons concerning security and flexibiliy. Keep in mind that a remote user won't work effectively in the middle of the night unless everything is already installed and configured. 2. RSView SE is more of a distributed application, meaning that you could install the software on other remote machines and expect central project changes to propogate. I think ME is more about Panelview Plus integration. I've heard some nasty things about RSView SE from integrators who really like (and still use) the old single user RSView 32. I've also heard cases of it working well. I recommend that you do your homework with respect to the software versus your requirements and evaluate it if possible. 3. A simple VPN solution is to get a home/"small business" router that acts as a VPN endpoint. A Windows 2003 Server with 2 network cards also works really well. Neither are too difficult to set up. Much depends on your infastructure. I don't think DHCP has anything to do with what you're talking about.

That was great feedback. I guess I didn't format my responses clearly compared to what I was quoting. I was supporting Alaric's comment. My first paragraph was supposed to go with the first quote and my second paragraph with the second. I responded

No problem - let us know how it goes!

If you're using a Windows VPN the client is built in - it's a lot like setting up the old "Dial Up Connections". You don't need a PC connected to the system - your client PC connects to the network directly. For some hardware VPNs you need to install a small utility like the Cisco VPN client, which isn't a big deal.

PoE is about the least important detail of what I mentioned - it's mearly a convenience. The real detail to evaluate relates to the latency of your Internet connection. VoIP doesn't take a lot of bandwith, but voice quality noticably degrades with latency. Implementing a QoS setup can work wonders. For me at home this was purchasing a D-Link "gaming" router and elevating the priority of my VoIP phone. The result, massive downloads/uploads and VPN connections no longer interrupt my phone calls. The clarity is perfect, even from halfway across the world. The other intelligent thing to do would be set up a separate VLAN for the VoIP phones, which helps segment broadcast/multicast traffic. The "small" setup used a PC as a "gateway" that could pull in both long distance and POTS lines. I'm not sure what kind of equipment it used (modem, card, etc), but know that it's possible. This works a bit differently if you have T1 voice lines, but is also possible. I would guess that there's equipment that provides female RJ11 and RJ45 jacks to do what you describe - that's actually what my Vonage Gateway resembles, except that it uses the "Vonage Cloud", not a local VoIP setup. I'd recommend contacting your local phone company for a quote. You provide them your requirements and they'll come out and give you a technically detailed idea of how to continue. It may not be a bad idea to let them set it up - the decision is yours. I strongly recommend evaluating the system beside your current one before committing unless you have a professional contracted to provide some specific level of service.

Anything that calls itself a "historian" and any HMI worth the disk it was installed from should easily support your requirement. You're right, devices like panelviews often just read the values as "realtime" and cache them in memory for a short term chart. It sounds like you want a system that records the values in a database. You have a lot of options here. I'm preferential to FactoryPMI, particularly if you plan on viewing the data from multiple stations. The graphing/charting engine is very powerful and it can deal with a lot of data stored in a standard SQL database. I'd contact Red Lion if you want a single terminal hardware (Panelview-like) solution. They appear to have more modern embedded software and seem to be popular on the forums. I wouldn't try to McGyver it as you mention in your last paragraph. You're mentioning a common problem that has been solved by nearly every vendor. Your decision should come down to additional project requirements.

I have some VoIP experience on a personal, small, and medium scale. I'd hardly consider myself a VoIP Engineer, but have some insight for you based on my experience on various scales: Personal - I use Vonage on a daily basis with a 'regular' phone plugged into a gateway. I dragged my setup around several countries on different continents. It worked great, including receiving calls. The pricing is amazing compared to phone companies, who think we still live in the 1960s. Skype is equally cool. These services are cheap, work well, and trivially simple to use. Small business - One clever but very inexperienced employee replaced about 10 phones with VoIP setup. He used a PC with some kind of cheap but very cool software as the gateway and managed to pull in POTS lines with a reasonable long distance service. Users were annoyed by quirks in the system that you wouldn't have thought of - call transfers, voicemail, which lines ring, caller id, out of office settings, etc. People just want a phone to "work". I don't remember any network problems, but all cabling went to one, maybe two interconnected switches. Small/Medium size (with a big budget) - Cisco VoIP solution. When the phones are set up properly they work great - usable (not configurable) with little training and feature rich! I was shocked and felt ripped off by the infrastructure commitment. You hear/assume "it works over IP - just plug it in your existing network". Not so! It works much better with newer VoIP capable switches. Beyond PoE, VLANs really need to be configured properly and QoS is a must, which aren't trivial. It took a few days of troubleshooting of our very talented Network Engineer to figure out what was making the phones all reboot periodically. Gatekeepers and Call Managers are not too difficult to figure out, but expensive. You can set up your own phone "number" system that's off the phone network, create conference call groups, elaborate call answer rollover schemes, easily transfer phone numbers for roving users, have some numbers ring on many phones, seamlessly forward numbers externally (to a cell phone) after a few rings, etc. The pricing of this type of setup can get staggering. Bottom line - VoIP provides a huge set of cool features at a great price (once in place). I highly recommend that anyone use a managed setup beside their normal phone. It can get pretty technical to set up/configure/manage your own rig, particularly if you have users expecting to conduct business with it. VoIP is better treated as "service based", like infrastructure where users better concern themselves with results over the details. Definitely TIAS before ripping out your existing phones!

Good point. Beyond tech support, stocking inventory is huge when something goes wrong. It's unlikely to have spares of everything on hand. Cumon guys, grow some and answer OPs question as to the general quality between brands. I favor the TIAS advice in general, but we don't have to pretend that they're all identical. That's a bit like recommending that a car buyer test drive a Kia versus a Honda to evaluate reliability.

To what extent are you asking about hardware versus software? AB makes top notch hardware. Fans enjoy the reliability, company commitment, and programming feature sets - and it's ex-pensive. I wouldn't say the same about their software in general except about the price. Besides the programming application (RSLogix) you're free to use other brands of software. I like PLC Direct. I've never heard anyone claim that the hardware is better than AB. Their PLCs run lots of facilities without problems. I've spoken to several integrators who swear by them and other who will only use AB. Does the quality justify the price discrepancy? I doubt it. It's brand snobbishness versus value - choose what you will. My prediction is that the gap will close plus the little guy has the option to do better things like include way more memory and processing power on their cheap lineups as technology improves. AB doesn't have the same luxury as they need to maintain a steeply tiered pricing model. The only PLC Direct software I've used is the programming software. I can't speak to the Omron question.

I like using gotomypc, but your IT department will probably be less than excited about using it for security purposes.

His post more closely resembled a flame than yours. Specific product experience and information is always a plus - particularly when it highlights different positive aspects of a system.

WOW - such insight! Information Exchange is much more precise and in line with my intent. I've been baffled and impressed for nearly a decade with Rockwell's "amazing (NA) market share" - your old IBM adage is as apt as the analysis that they've had a history of orphaning users who generally keep returning. This is a case where a lack of education clearly favors the encumbant. It continues to surprise me that even Wonderware, the longtime niche Industry King, doesn't carry that misplaced warm feeling of longevity that devout Rockwell fans are confident in. They will tell you that what they're paying a premium for has been around for 20 years and will work into the future - oops are we confusing AB PLCs with software? In what other industry do you go looking for old software? Have they forgotten getting "had" the last several times or about the expensive RSSQL or Plantmetrics bookmark sitting on their shelves? "Yes, a Panelview Plus is nicer - you'd want to re-write your applications anyways", "Supervisory Edition is completely re-written to be a distributed application - surely that's more important than an upgrade path", "You've never heard of FactoryTalk, it's the new standard, no it won't work with your existing system, but it's for sale". Users are confident in the quality because of the size of the customer base - or think that it must get better for that same reason. I've spoken with numerous users who are unhappy with the product, but assume that the competition "must be worse" and users who "know" that you don't have to match the brand of hardware and software, but don't really believe it. Shareholders be glad - this impossible phenomena doesn't seem to be going and it's reinforced by corporate standards. I like to think of Rockwell like Microsoft in recent OS battles. Instead of the best dang office suite their secret weapon is a really great PLC hardware platform. A blog post highlighted the fact that a staggering percentage of Apple users gladly spent over $500 in recent OS upgrades (Tiger to Panther to Leopard, no discounts) whereas every Microsoft user I know would balk at a $250 copy of their latest. The difference, the blogger pointed out, is that your programs and devices will still work on your "new" Mac, you even get a few new useful utilities and interface upgrades. The equivalent Windows upgrade is sure to be a gamble - you can bet on the fact that things will be different. Of the list of advertised feature ideas, the ones that made it versus those that didn't will baffle you. Whereas the field, Apple, focuses on useful minor upgrades, Microsoft is busy overkilling past deficiencies and re-inventing an interface that their public is happy with. This applies to Rockwell's software history. Think about it. The only point on which I beg to differ is your 2nd to last paragraph (though I agree with your message delivered in the last 3). First, I'd claim that automation level communication standards are stronger than ever and meet customer needs. OPC has transformed from something that vendors supported just because, to a platform allowing any product to talk to nearly any piece of hardware. Software vendors include increased native driver support, some open source exists, and there's always Modbus. What information exchange standards are you referring to? That's where I feel this industry is really lacking. There's no cross platform support for FactoryTalk or Archestra and OPC UA remains more of an idea. SQL Databases are the greatest common denominator in the absence of an XML/web services model. To my understanding the big guns, Oracle, SAP, and the like, don't have a foothold in this space. Frequent the forums here and you'll see that users still fight custom programming to facilitate data transfers. This is greatly efficient - if you happen to be Wal Mart sized with a team of full time programmers. This "stove piping" hurts the rest of us. The goal, as I see it, is a ubiquitous environment where everything you want is connected and additions are easy. Operators create product from a panel, accounting has real time visibility from their software application. The real challenge is, for example, allowing management to install a new reporting package from a different vendor and having it "hook" into the existing system without hundreds of hours of integration. That same day, a plant manager should be able to call up his regional manager and show him how to securely check it out from his remote site. That's why we need the capability driven, vendor neutral standards you describe. A lot of collaboration needs to occur to make this feasible.

Very interesting commentary - thanks for sharing it. I'd be curious to get more details from the author on how Rockwell helped it's position immensely. I believe that "compatibility" with their existing projects is significant to the usefulness of the authors implications of such a move. Keep in mind that in this focused nitch industry, a company of Rockwell's size might buy out a much smaller company with a dangerous project just to get rid of them. That said, my opinion is that the reuse of "good" code will benefit all. It's too common that that the big players in this industry invent their own half-baked implementation of existing projects. Expect comments on this on my blog after more research. I'd love to hear other opinions on this.

I'm not sure that I understood your question, but you could use bigger data types. Use a float or a double instead of an int. If the timer doesn't support it directly then use another register like a place value system. When the timer gets to a certain value reset it and increment your other counter.

OK, Pierre - I should have given you more benefit of the doubt. I remember you from other posts and did a "double take" as it seemed pretty obvious. This is one where Ken or other Rockwell guys would be the most help, but I do have a few ideas and comments. 1. A Control Logix PLC can be used to interface with the PLCs and OPC Server as you described the role of your single "PLC 5 Bridge". You'll need to dig deeper with an AB expert on this one to determine if it would help in your case. My thoughts are that it depends on your backbone - how you program your data transfer, etc. 2. I'm told that KepServer EX outperforms RSLinx in a large setup. That probably doesn't help you much for the 10 clients each banging at the PLC (ouch!), but could help for your data logging portion. You really want to do what you can to aggregate the data requests with respect to your PLCs. Kepware has a free 2 hour trial to evaluate it. 3. The painful thing about lots of standalone RSViews is that they each connect to the PLCs and poll separately. Obviously, you'll want to push this as best as you can so you don't have to purchase more/recreate your application. Try slowing down your polling rates or creating a setup where idle PCs log off or jump to a screen that doesn't communicate much. You can check this in your connections listing in RSLinx. 4. I don't know enough about RSLinx Gateway to determine if your idea of using it would help. Gateway allows other RSLinx instances to connect through it. If it was well written it would group the requests from all clients and only hit the PLC once. I don't know if this is the case. The other question is whether RSLinx OEM instances can connect through a single copy of RSLinx Gateway - that's about the only way it could be cost effective. 5. I agree - trending data every second is retarded on a 24 hour display. How much historical data do you maintain? 6. Getting a newer managed switch may be a good idea. The more important point is to determine the load on the ENET module - I'm not sure how to do that, but AB/Rockwell should. Keep in mind that it's typically connections, not raw data that is more likely to overload your PLC Ethernet connection. I'm sure your hunch is correct - some good 'ol configuration management is the best step. I'd start with actual requirements things like: "see a 24 hour snapshot of data on a graph", NOT "log data every X seconds" unless it's driven by a real (legal/regulatory) requirement. Also, in theory, a distributed system would help you out, but keep in mind that it adds significant complexity. Don't let them sell you a "newer" software solution without considering engineering/development time, maintenance, etc. It's like the saying "The cheapest car is the one you already have". It sounds like you don't have a lemon or need a minivan - just a tune up.

Wow - good catch! I'm impressed.

I really doubt that the ENET module is your bottleneck on a system with 2 PCs and 1 PLC. I'd be surprised if a PLC5 could drive the I/O to "top out" one Ethernet connection - I could only imagine another slowing down responses to the client(s). What do you mean by "slows down the system"? One obvious thing to look for is really high speed polling. I think you're right about RSLinx Gateway - it won't change a thing unless you're planning on a significant distributed restructuring, which doesn't make sense with 2 PCs.

I have a colleague who's created really incredible "industrial marquees" in this fashion with FactoryPMI (you could use any HMI with this technique, but FPMI offers a few specific supporting features that work well here). His approach uses cheap PCs or thin clients to drive the display. If you're using large, high resolution displays (LCD TVs are the best, followed by plasma or projectors) you really want to use a DVI/HDMI input. There are Ethernet based (non-TCP/IP) extension devices, but it's still pretty knarly and expensive at that resolution. Your screens will probably look pretty basic since they're designed to be viewed from afar. You still want to develop them at the native resolution of the display. A cool thing about doing it with FactoryPMI is that you get unlimited client licenses and that the "install-less" Java platform makes it really easy for a basic thin client or cheap PC to run. You just need to figure another $300 or so and a network connection on top of each display. You would then use a table in a centralized database that stores the screen or pre-defined rotation for each computer (marquee). This allows you to centrally control what each monitor displays without messing with remote control software. As a different approach, at work we use NTI brand devices that have video switches that work over Ethernet over Cat 5/6 (again not TCP/IP). It's pretty slick, but expensive and you only get the relatively low resolution DB-15/VGA. There are input and output VGA boxes, both plug into an RJ45 jack. Each computer that you want as an input goes into an input box, each monitor, plasma, LCD, projector goes into an output box. A digital switch allows you to simultaneously map whichever outputs to any input. I think our units support approximately 10 inputs 10 outputs. Here's a $3600 unit that supports 8 inputs and 8 outputs. That unit has all the outputs builtin. The one we use has little Cat 5 extension boxes - I think they're nearly $500 apiece. We do such things with VTCs, Powerpoint slides in multiple languages, and video where the conference may be in different rooms. For your application I would recommend the former approach (centrally controlled individual HMIs driving the displays rather than dealing with video extensions).

Your points are correct. I'll comment in general and specific to this application. For the record, I am a fan of stored procedures. What I want to convey is that they don't get appropriately utilized and tend to complicate things for this sort of application. Users are taught that it's the only way to go, don't understand why (nor should they need to), and as a result, don't functionally gain anything from it. It's like if you were only allowed to write a PLC program using indirect addressing when you first learned how to program! 1. Not only are they pre-compiled, but they tend to remain memory resident in the server. Great for some applications, negligible in most cases here. These guys typically want to populate data from a SELECT query as a rare event, and that usually comes from a single table. There should never be reason to have sensitive embedded data in the same table like your example. 2. Stored procedures are great for a "black box" programming paradigm. However, the majority of these simple applications run the generated queries locally and distribute the data by some other means (or are stand alone). That's not to say that they're not vulnerable to SQL injection attacks, but these guys have much bigger worries from a knowledgeable hacker, like DCOM vulnerabilities. 3. You are correct about being able to lock down user permissions to specific stored procedures. In a financial setup this is very important. Most of your RSView users aren't DBAs, heck, they usually use the 'sa' or 'root' root account. Much tighter security can be applied with or without stored procedures - the latter can provide more granular control, if that's the only thing your project uses (with that account). However, let's take a step back for a dose of reality. Without a lot of extra, weird programming, these applications do not authenticate users separately with respect to the database! What I mean is that they don't run queries with the permissions of the user, they run it with a "system" or shared account. Even if you did lock down the system to what the most powerful user could do, you're hammering the principal of least privilege. These systems store the authentication credentials either in the script, or in the ODBC connection! In a theoretical argument you're correct, but nobody ever does it that way in RSView! They don't even come close! My big gripe is that they're using stored procedures for simple SELECT queries. Code is scripted in VBA, the system typically executing queries on the same machine, running from the same source on the same destination. This forces a de-coupling where it doesn't make sense or provide any benefit. It's like the general asking the sergeant to order the private to tie his shoes when the 3 of them are the only ones in the room. The user just wants to populate data in a table. Every step along the way is more complicated. As far as security goes, the application doesn't functionally support locking down the system to the point where having the granularity of security for stored procedures matters. Besides, the system has other gaping issues for a real attacker. It's like upgrading your locked metal cage to a vault door when there's a huge hole right next to it. The idea behind your salary example is a good textbook argument for stored procs. In this case the whole application runs off the same username/password, so you'd better separate those salaries into a different table and lock that one down!

[rant] This is out of control! Surely vendors realize that it's not the 1960's anymore. How much would it really cost them to expand 10k of memory an order of magnitude or two?[/rant]

SQL isn't that complicated to learn and it's very powerful - that's #1 in Paul's response. As he suggests, W3Schools is a great tutorial. There are other sites too. I like SQL Zoo. I also love the book Head First SQL, although it is geared toward MySQL. #2 will be a process since you're using RSView so you'll need to learn the stored procedure stuff and old bits of VBA. I never really understood their infatuation with stored procedures. They miss the potential great benefits of the feature, effectively only introducing the complexity (I'd love to get into this debate...). #3, the VBA and ADO thing may be welcome if you're a geeky object oriented programmer, but probably confusing otherwise. A lot of the object model has to do with things like establishing your connection, credentials, and create a data object for you to loop code over. A nice frontend (which can be part of an HMI) will roll these into user friendly one time configurable connections and GUI fields that create the tables/etc for you. There's a lot of programmatic plumbing that you have to deal with in this case. Do lots of copy/pasting and follow Paul's advice and you should be fine here.

I like Snagit from Tech Smith for simple documentation. It's no Photoshop or Gimp, but great for docs and screenshots.