Nathan

The free 2 hour demo of FactoryPMI should work great for in house testing and visualization. You don't have any tag or screen limits, but you do need to "reset" it after 2 hours of continuous use (10 second process). It will install and run fine on a desktop PC, and the application can be launched on any machine with Java installed across the network with a web browser. I recommend installing it on the same machine as your OPC Server (RSLinx/Kepware/Matrikon/etc), although you don't have to. Download here if interested.

It's Wireshark now. OP - do you need to test wiring/switch performance or are you looking for existing traffic?

RSView32 probably can't do what you want natively. Don't go down the custom programming route (it can run VBA scripts) for data logging. What you need is a "historian" or "data logger". I highly recommend FactorySQL. The Rockwell product is RSHistorian, which I think runs on it's own custom version of MS SQL Server. There are other products in this category.

It's a good administrative tool set. This approach is typically not ideal for users since multimedia doesn't work as well. It will probably work fine for 1 user. You need a "Terminal Server" to allow multiple concurrent users. This may or may not work with your SCADA package based on the licensing and file lock/concurrency type issues. The best way is to give it a shot. It's easy to allow "Remote" control then use Remote Desktop in Windows (mstsc.exe).

Rough times. Good luck to you.

We also need specific symptoms and what you've done. The original post is like saying "My car doesn't run - what's the problem?"

If the external hard drive has an IP address, then it's probably a NAS device. I recommend mapping the share as a network drive, something like "net use z: \\ip_address\share password /user:username". You can then work the Z drive like a local one. Please provide more detail with regard to "getting a list of file names in a certain format to run certain recipes". That description doesn't adequately provide what you're trying to accomplish. But you are correct, your CLX PLC won't be able to do it without a PC and it does sound like an RSView VBA scripting task.

Does it have a Blu-Ray player?

That's what any new consultant would do in that situation, including myself. But do you really feel that the hardware owner shouldn't be able to make minor modifications if the original programmer is unavailable/unwilling/deceased? To me it's like having a registered software application and being denied known bug fixes. That is, unless you hire someone else to rewrite it all from scratch - ridiculous in some cases. Like I said before - in a similar (albeit important differences) computer networking case, Mr. Childs was fired and imprisoned for such behavior.

Paul - what's wrong with using Cisco 3750s (besides price)? When "installing an Ethernet network from the ground up" (OP), your equipment will reside in an air conditioned room.

I respect the terms and intent of this forum. However, it's worth mentioning that most hardware that you can physically access has a "password recovery" feature by design. This is very different from, "I've lost my software key, how can I crack an application" type requests. In one case you're probably stealing software, whereas in the other you have the device, but are locked out of it. I find it odd that many PLCs fail to implement such features. A "data recovery" service for PLCs may be an interesting business opportunity. It would surely be cheaper than re-writing your application after being screwed by the unfortunate... BTW - respectfully, I don't buy the "intellectual property protection" argument. Hardware vendors don't need to have the interests of consultants who get paid to do one time jobs on other peoples equipment. The consultants/contractors/integrators (I've been there for years) are always worried about protecting their "proprietary" "secrets". This is BS and everybody knows it. When you have to "re-write" someone else's work it isn't because you have access to their source, it's because you don't like how they implemented it. How many times have you looked at someone else's PLC code and said, "oh, I have to copy/reuse this!". >99% of the time there isn't any intellectual property that isn't common trade knowledge. You simply don't have that much flexibility in ladder. You'd have to have a whole vertical industry business built around some proprietary method to even began to have an argument. This is clearly a case where contractors are protecting their job security by being the only ones who can work on the system. This is unethical, like the case of the SF network engineer. I will re-iterate - PLC programming is much more like configuring network hardware than developing a software application with respect to intellectual property rights!

Ha, ha. I think the Kiwis are going to strike back, though. The Scottish Corporation will join them.

The takeaway here is: 1. Determine your requirements 2. Come up with an addressing scheme that makes sense 3. Fix your issues during scheduled downtime This is a really simple problem with a simple solution. The "Band Aide" fixes are complicated, expensive, and ultimately create problems.

I hear you. Unfortunately changing the subnet masks represents nearly the same amount of work (downtime) as changing the address range. You can do it with a router, but you'll need someone who knows what they're doing with networking. I'm not usually a fan of saying that you need an "expert", but this is one of those cases. The potential exists to create more downtime in a failed implementation than you would by correcting your address scheme.

Yep ugly. Bad idea. To clarify: 1. I think a subnet mask of 252.0.0.0 would do it. You are combining an (RFC 1917) non-routable range with another range. Very screwy. 2. Binding multiple IP addresses could work. Try it out - I've seen this randomly "lock up" industrial hardware before. 3. NAT would work, but any cisco router could route between the 2 networks. Just like the "router on a stick" CCNA labs with subinterfaces (or separate interfaces). Seems really silly, though... Why not just change your address ranges to something that makes sense?

Thanks for the tip. Agh, the beauty of Coraframs...

If you have a PC and RSLinx (non-Lite), FactorySQL would run you $1995). If you have an experienced (VBA, most likely) programmer and an existing HMI platform, you won't need to buy anything. Let me emphasize that this is not an easy problem. Going to a suitable hardware platform is another option, but why start over just to add a feature to something that already works? It doesn't strike me as a time-efficient solution. Paul's advice is always very good. However, I disagree on one point. Based on your description, I would use a barcode reader that's controlled via the PLC. It makes more sense for the scanning (and the lookup response) to be handled automatically. I have set up HMI applications that used Wasp barcode scanners as the input. They are really slick! However,it's most applicable when the user needs to control the flow of input or see output based on the scanning process.

TW - excellent advice on all responses. I agree. Paul - you're officially not allowed to complain about long winded posts

Users on PLCS.NET are reporting not being able to get to MrPLC.com. DNS resolution appears to be working for all. They are from a variety of non-US countries. I can access this site fine from Korea. http://www.plctalk.net/qanda/showthread.php?p=303476

Nagh - pretty obvious that it was an ACL issue (see troubleshooting speculation on PLCTalk). Most of them could traceroute up to the last leg. Routing protocols do a pretty good job even when major links drop. They'd be randomly getting timed out instead of dest host unreachable errors. I tried to first describe the problem from a non-technical perspective. I hate when people come to me with an IT problem framed around their attempted troubleshooting. That info is good, but not in describing the problem~especially when they don't know my system or I'm dealing with known outages. Where can I read about the cable issue?

Good point! A Basic module should have the computing power and memory (pls verify) for this. It'd be a fun project. One tricky part to think about is how to modify your part list without going into the program. That may or may not be an issue depending on who's making changes and how frequently.

Ha, ha - Awesome! I wasn't buying the NAT explanation, but I'd never thought about changes to unassigned subnets! Makes you wonder how many of the Internet routers still block these in their ACLs... Thanks for the fix and the lesson Chako.

mckeand13 - I love to talk algorithms as well. Pete, Paul, and I can spar all day on related topics. This (batching) is a tough one. The short answer is that your Micro won't be able to tackle this task alone. I guarantee that doing this project with script or custom code (or trying to do it in your PLC) will be a time sink and a headache. Even when you get it to work, this is the type of application that will not be robust on its own. I've been down this path before. If you're looking for a pragmatic solution consider the following. It would take me a few hours to install and configure FactorySQL to: 1. Read the current barcode when the PLC triggers (changes resister value or sets a bit) 2. Queries your SQL database for the result. (After importing your spreadsheet) 3. Writes back to the PLC indicating the result and that the "transaction" is complete. You'd have to purchase software and an OPC server to do it my way. In any case, you're looking at a PC based solution.

No cost - I'd go Panny Toughbook. Improvement suggestions - "real" serial port, and the use of virtual machines so that you can support different operating system and programming tool/HMI versions. My preference for a laptop as of now is still 4 gigs of RAM and a 32 bit OS. My dream virtual server, on the other hand,...

To add my $.02 to Paul's good advice. 1. A router could absolutely solve your problem. However, you would need someone who knows what they're doing. This is very different from sharing your home Internet connection via a Linksys device. It probably does make sense to segment broadcast domains (what a router does) between separate processes. Paul is absolutely right - even if you wanted this type of configuration, the proper way would be to use "non-routable" (RFC 1918) address ranges. It sounds like you're trying to patch up a mistake. But if downtime is money, you can do it. Document the heck out of whatever you do! Network guys are bound to look at you with very little respect until you justify what you had to do to upgrade your legacy system. 2. If your network will always be physically isolated from the Internet then the address range isn't so important - skip this answer. You can share Internet access using a proxy server or "real" router with IP addresses that aren't yours. It's considered to be poor practice by convention for several good reasons. This is another task that will need more expensive hardware and an "expert". Contrast that to using 192.168 addresses where you could set this up yourself with a Walmart router. 3. For your question #2 - the PLC programming and SCADA package operate at a "higher level" than the router. 4. Go with static IP addresses for PLCs. DHCP for clients. For central management I often prefer using DHCP with reservations for servers and printers, then accessing them by name (DNS takes care of this for you). This would be ideal for PLCs if the hardware and software wasn't so primitive (ie, RSLinx Ethernet driver only working with IP addresses instead of hostnames, PLCs using BOOTP instead of DHCP, etc). 5. Router advise - use whatever the person implementing it is familiar with. I like Cisco. BOTTOM LINE - unless you have a compelling reason to do otherwise, you're far better off actually planning an appropriate address scheme then cutting everything over at your convenience. This will save you trouble and confusion, especially as you expand in size or capability (VPN between sites or for remote users, providing Internet access, increasing security, etc). Paul - you seem to be framing your response in a specific non-applicable context. A few of your statements are factually correct, but misleading. 1. About routers being intended to work on "small pipes". Sure they have general purpose processors instead of ASICs, but 100Mbs is a "small pipe". Keep in mind that traffic will only go through the router when communicating with another subnet. It's not going to slow down his network in any practical sense unless he designs the system to be asinine. 2. About IP addresses wanting to be hierarchical. True, but irrelevant in this context. He's not using RIP and he's not engineering an enterprise architecture. He'd be using CIDR and could achieve all the same effects with a set of screwy ranges. There might be a few more entries since he doesn't get the benefit of route summarization, but we're talking about a very small setup, with probably only 1 router. 3. OP never brought up NAT or "remapping" - you did. He wanted to communicate between nodes on different IP address ranges - that's what a router does.