Nathan

Recent Windows update has been screwing up a lot of software. Might be the 2.0 .NET frameworks update. There are other patches. Doing a system restore (as previously suggested) can often "fix" the problem.

I'm a fan of Wyse for thin clients. Different versions all run trim operating systems that are based on: Windows, Java, Linux, Unix, web or even "stateless" that require a network source to boot from. Sounds like the Linux ones would be right up your alley. They're cheap devices and don't require you to know (or do) nearly as much as trying to customize a Linux PC installation for this purpose.

Does it support the .png format? If not, .gif should deal better with transparencies than .bmp.

The "console" session is something that you want to be aware of. It's basically the instance that the monitor/keyboard/mouse normally connects to. Sometimes it's nice to connect to a session that nobody's on (like using RDP on Server 2003) and other times you may want to boot someone off the "console" session (VNC does this, as does running RDP with the following command "mstsc /console").

Dameware is a great tool. Be warned that many anti-virus detection tools flag it as malware since it's equally useful for a would be attacker. VNC used to be the bomb, but as Paul suggested RDP is now a better product.

No problem, happy to help. What do you want the web page to do? Display realtime values, "history" tables or graphs? Read only values? Or setting setpoints, adjusting modes, etc? Your start should really be requirements driven.

Sure, this is the right forum. edit - The Micrologix has a built in web server. Maybe something similar is offered for Control Logix? http://literature.rockwellautomation.com/i...um002_-en-p.pdf DDE with Excel is a cheap and relatively easy way to go. I consider it to be a reasonable way for a technical user to make life easier. It won't deal well with concurrency, and, from personal experience, I can tell you that providing it as a service for non-technical users will require some support. There are also security implications with this model. Also, bad juju when it comes to logging historical data. A PLC/OPC driven web page is a sweet way to go in that it provides concurrent access to process data to your entire network. It is scalable (multiple concurrent apps, Excel instances or single seat HMIs, for example, directly accessing the PLC can cause bad things to happen), easy to access without a setup procedure, and can be made secure. Many HMIs have a rudimentary builtin web capability, either included or sold as a plugin. While these aren't very flexible, they are easy to use. The web server is builtin and the content generated for you. This doesn't seem applicable based on your post, but it's good info to know. The main step to rolling your own web page is synchronizing the OPC server to an SQL Database. Writing your own code to access the PLC directly is possible, but I would highly discourage it. A program like FactorySQL will provide this "data bridge" functionality. There are a few programs that do this. Just make sure that they're easy to configure including a "bi-directional" capability if you have any registers that you need to update from the web page. An example would be a temperature setpoint that a user could change from a panelview or the web page. Every dynamic web site that I know of, including Internet sites and MrPLC.com, use database driven websites. You have an engine that runs on your web server that executes code then outputs HTML. Examples are: PHP, ASP, Cold Fusion, Java Servlets, and many others. If you're not comfortable writing code yourself you can use a builder like CodeCharge Studio. I will warn you - once users see that they can access data from anywhere they'll keep asking for expanded capabilities. One thing that web pages aren't good at is efficiently refreshing data and doing even simple animation. These can be accomplished with AJAX, Flash, or Java applications, but I'm guessing that you don't have a full time web developer on hand. That's really what led to the creation of FactoryPMI. If you want both the drag and drop WYSIWYG capabilities of an HMI coupled with the ability to run it anywhere on your network via a web browser that's the way to go. In summary - if you need a peek into your process for a couple of technical users, or users who have support on hand, DDE+Excel approach is free - just make sure "realtime" is your goal, not "historical" data. The easiest (not necessarily cheapest) way to display data in web pages may be to use a software package. The best way to roll your own pages is by using an OPC<->SQL "databridge" then creating your own dynamic web pages however you want.

Does it work on any other computer? Has it ever worked? Please copy the entire output of the console.

Based on the posts, I don't have a solid idea of how you want the system to operate. Could you provide an example of what you mean here? Are the "desired moments" user configurable or preset? Are they based on a calandar, time interval, user action, process information, or a combination? What about the dynamic setpoints based on preconditions? It's important that you figure out exactly how you want this system to function in order to simplify the setup. This will get you a lot farther than "shotgunning" features that seem appropriate in the "idea" phase. I'd recommend writing a list of "rules" for how the system should behave. I bet you'll be surprised in what a "plain" HMI coupled with a PLC can accomplish.

That's right - I was referring to X-Coupler. That's the only SQL Database logger that I know of that works with AB and runs entirely in a module. I'm pretty sure it's just for Control Logix. I think those other modules are gateways (devices that translate between protocols). That's not to say that a SLC module data logger doesn't exist...

Paul - I know several vendors make data loggers that fit in Control Logix modules. I haven't heard of any that work with SLCs or PLC 5s. It's a really cool idea. However, based on my conversations with several integrators, they tend to be expensive and inflexible. (I'm not sure what vendors they dealt with, so I can't say "yea or nea" to Prosoft). It is an embedded device, so I can image what the vendor would have to do to program it. That said, I'm sure these will get cooler and cooler over time. I'd love to see one that's totally configurable via a web page that plays nicely with SQL databases and SCADA systems. Just make sure that it does a good job with data caching - that's your one distinct advantage of going that route. Also ensure that it can log to an SQL database. The units that write their data to a .CSV file then upload them as separate daily .CSV files will complicate your life in the long run.

While it's a nice idea to have a hardware device do your data logging, it often works better to do so in software. Much depends on your exact requirements - engineering a "solution" isn't about a "one product fits all" approach. For Historians/Data loggers in general, a hardware implementation should be more robust, and software more flexible and capable. Since your historian will run on an SQL database, you necessarily have PC(s) in the mix for this type of application - and that platform can easily run a data logger as well. The one distinct advantage of a hardware approach is that it can cache a limited amount of historical data if the PC or network connection drops. Weigh that against the fact that they're: more expensive, less capable, less upgradeable, and not centrally managable and you have a compelling argument to see what software is out there. PS - I'm assuming an expandable and robust, database-based approach. If logging to text files meets your (usually legal or regulatory) needs, then a hardware device alone could satisfy your requirements. However, I have a million and one reasons why it's a bad idea to use Excel or text files as a Historian.

Paul - I must have missed this post. It sounds like an ideal application for Inductive Automation software. As usual, your advice is sound - I only offer a few points to fill in some gaps. FactorySQL can work as a simple drag and drop datalogger, or be used as a tool to work into "historian" and "MES" type applications. The addition of "Historical" SQLTags should bring FactoryPMI on par with any other historian (as a "historian") out of the box.

Glad we could help

Pretty sure RSLogix 500 is still not Vista compatible. Short of running VMWare or another operating system I think you're out of luck.

Check out FactoryPMI. The license is a flat fee that would allow you to support your entire process and grow. It supports many "web based" scalability technologies. You wouldn't need to consider runtime licenses - unlimited concurrent Java Web Start runtime clients can easily be launched from any computer on your network. I'd recommend downloading the fully functional trial - it's only limited to a (resettable) two hour runtime period. Other vendors to consider include: Rockwell, Wonderware, Iconics, Citect, Intellusion, and GE. Be sure to investigate licensing costs as your process grows.

Got curious so I posted the question on PLCs - the answer included an AB knowledgebase post. Seems to me that it's more of a legacy wrapper. http://www.plctalk.net/qanda/showthread.php?t=37828 http://www.plctalk.net/qanda/attachment.ph...tachmentid=7906

A quick search yielded that deleting "Harmony" can fix a myriad of other weird RSLinx issues. The name rings a bell from using RSLinx in the past, but I can't place a finger on it. I'd really like to know what it is and does.

Paul - great advice! One thing that hasn't been addressed is determining how/where you need "hooks" into your process. Often you can simplify things and improve security by limiting points of communication. Let me give you a few things to consider. 1. Do the PLCs need to communicate with one another to run your process? Are they already doing so? 2. Do the HMI clients really need to communicate with all the PLCs? Keep open to the possiblity of adjust SPs, trigger actions, etc, in one PLC. 2a. Do the clients need to communicate directly with each PLC? If you're using a distributed application this may be totally unnecessary. For example, FactoryPMI clients need only communicate with the FactoryPMI Gateway. I would generally recommend against RSLinx Gateway (RSLinx OEM would be your better buy - or Kepware or Matrikon). The big feature that you get for all the extra money is remote connections via DCOM, which is difficult to configure, impossible to secure, and a pain to work with in general. The easier, secure approach is to use an OPC tunneler, which runs on "each end" and encapsulates all the COM nonsense over an encrypted communication stream via a single, user defined, TCP port. Here's what I'm getting at. If your process already works, then set your system up so that user I/O goes through a single PLC. That PLC would be connected directly to a single PC by any means - a serial cable for all I care. That PC would host a distributed HMI application. Any computer on your network should be able to run/program it. Assuming PLCs are already talking with each other, HMIs would have full capabilities to trigger/set anything on any PLC. Notice that none of the HMI clients communicate directly with any PLC! This abstraction provides great flexibility. That said, it'd make your life easier as a developer to put all the PLCs on one network and get one or more PCs on it too. Ethernet, Blue Hose...whatever makes the most sense for your existing setup.

You might seek idea screens elsewhere. You should be able to emulate the "look and feel" from just about any vendor. Try searching Google Images with different combinations of "HMI, SCADA, screens, RSView, Wonderware, iFix, Citect, FactoryPMI, etc". You should be able to come up with many examples for inspiration.

Does rebooting the HMI bring the connections back up? You might also try restarting Linx. What exact version of RSLinx are you running? Are you running it as a service or application? I suspect that your troubleshooting should begin with RSLinx. As a sanity check, note CPU and memory usage of RSLinx before and after the problem.

A number of posters have asked for hard numbers in terms of performance for tags stored in an SQL database and concurrent clients in FactorySQL and FactoryPMI. Here's a summary of the results and the full whitepaper. In a nutshell, FactoryPMI Gateway - With a small server, expect between 70-100 clients at a time, depending on the size of your project. With a large server, 150+. FactorySQL - depends more on changing tags than total number. Systems with upwards of 250,000 tags are feasible, as long as only a small percentage of them are actively changing every second. Tag throughput for a low-end server or high-end desktop computer, ranged between 2,500, and 13,000 tag changes per second.

A 4-20 mA signal is standard. I'm guessing that 1000 discreet values represents your accurate resolution. Given that, your chosen value range is 0 to 100 in steps of 1/10. You could have just as easily picked 1000 to 2000 in steps of 10. It makes sense to me to first get a discreet value from your input before running it through your linear interpolation. Perhaps there's a standard that I'm missing...

If you're dealing with a system where the MS (PC) sends the alarm there isn't much difference between the 2 conditions you stated. Either the exact alarm is determined in the PLC or MS - that's largely up to the PLC programmer. "Severity" is something else that most software packages include, but you could implement your own system at the PLC level. In both cases the SCADA software is probably polling/subscribing to the PLC registers at some regular interval. The tough part about event driven communication is generalizing the handler on the PC receiving end - I can't think of an application that works this way that isn't custom written. It turns out that a polled system, with a driver that implements caches, etc, works well for most applications. It may be chatty on the network, but is functional.

Taking a step back for anyone needing it. Node here is a device on the network - PC, PLC, router, etc. Usually I'm referring to Layer 3, so it has an IP address. Collision - Bad juju. The "red light on a hub" 2 or more nodes sending a signal on the same wire. A Collision Domain is a network segment where this can happen. A Broadcast Domain is a network segment where nodes can communicate directly (without going through a router, or equivalent). The good is that it's easy to talk. The bad is that it's easy to talk. Each node will inspect each broadcast/multicast packet (DHCP requests, streaming video, chatty traffic, etc). What's an Ethernet hub? It's a dumb device that gets a signal on one port and retransmits on all ports - like everyone yelling in a room. One Broadcast Domain, one Collision Domain. Great for running packet sniffers (programs to inspect all traffic). Poor for performance. What's a bridge? A bridge effectively combines nodes, or sets of nodes in separate Collision Domains, but they maintain one Broadcast Domain. So you don't get as many wire issues (network performance problems), but everyone's still listening to everyone. So what's a switch? A switch is what you get if you bridge each port together. One Broadcast Domain, but a Collision Domain for each port (or set of ports??). In any event, you shouldn't get collisions, but everyone is still listening to everyone else. Everything described so far falls under Layers 1 and (mostly) 2. So assume you want 2 "networks", office and plant. We might set up 2 disconnected switches. Traffic doesn't pass between them - they're in 2 separate broadcast domains. Suppose we put the two on separate IP subnets (a layer 3 concept). We could bridge our 2 switches with a crossover cable. It will seem like devices on one switch can't talk (directly) to one another. That's because they're on separate IP networks (layer 3). But, nodes on both switches will listen to broadcasts from each other. Remember, our bridge maintains a broadcast domain. The fix to that is putting a router between the 2 switches. A router is a device that has 2 network cards, one on each network (logically and physically) that can pass layer 3 traffic. Now chatty traffic won't pass between switches unless it's directed to an address and goes through our router. Note that your router doesn't know about ports/traffic type, that would be layer 4+ and we'd be talking about a firewall. This is a good place to ask yourself - does this all make sense? If so... A managed switch allows you mess with port level settings, VLANS, and things like that. A VLAN, "virtual local area network", is a logical layer 2 network. Think of it exactly like our "separate switches" example. If we set up the top half of our managed switch ports on VLAN1 and the bottom half on VLAN2, it would appear to users as if they were plugged into separate switches. In fact, we could plug a physical router into both VLANS and it would route traffic as we described in our example. The cool thing is that you can segment VLANs by things other than physical ports (like hardware addresses) and that you can change settings without rewiring anything. This allows you to "spread" your network as you grow. As you get more into networking you realize that a lot of the concepts are more flexible to deal with logically, rather than physically. Things also get crazy as you introduce: Inter-VLAN routing, DHCP proxies, and policies that selectively pass higher/lower layer traffic. There are also concepts like QoS (Quality of Service) that can substantially improve network performance with the same amount of throughput. There's also a lot of things that can be tuned (packet fragmenting works with frame size, latency issues, security stuff, "packet shaping", etc) that come into play if you have bigger networks especially with encryption devices, VPN tunnels, satellite links, etc. Lots of cool stuff to networking, but if you understand the basics that I described here you should be on your way. (Paul's advice is solid - hopefully this post helps clarify some of the assumptions).