Nathan

Sounds good to me. That would be all vendors, right?

That, and your willingness to learn and tinker, are the most important qualities of a potential great PLC programmer.

Bob - great advice. Do you consider VLANs to be "separate"? I can be swayed by arguments of physically separating equipment and locking it up because knuckleheads do stupid things. It is important to convey to IT that they communicate with you prior to doing things like firmware upgrades if you're riding their infrastructure. I still hold that they can provide you with better services and support (at the transport level) than you may be capable of doing yourself (unless you live on site and happen to be a network guru).

I think that "home" VPN routers are limited by design to providing access to class C non-routable addresses (192.168.x.y), which is where your PLC range should be anyway. The source IP range shouldn't matter as you get an address in the host range. The caveat being that it can cause problems if your local and remote networks occupy the same IP space. I would recommend using 192.168.0.y (or any number other than 1 in the place of the 0) for your PLC network. A switch will provide additional ports. All you need is a crossover cable to connect the two. I'd recommend a managed switch so you can separate your network with VLANS. Cisco equipment should work fine with whatever IP scheme you're dealing with, but I can't think of a good reason to use 123.123.123.x.

That's really a great question. It depends more on your requirements than a cookie-cutter answer can provide. The first question is, "why?" If you're into separation for absolute security the answer is simple - physically divide your networks. For most applications the gain comes from the front office gaining process visibility and the plant floor gets the benefit of IT resources (VPN access, data logging to SQL databases, etc, etc). My recommendation is this - if you don't have a clue what you're doing, keep the networks separate - it never gets worse than the obvious. A poor combined setup, like hubs daisy chaining busy networks together, can be dangerous. But controls guys tend to exaggerate the problems. They have a bad taste in their mouths from misapplied older technologies. Also, the convergence of IT and controls will give you less and less liberty to make that decision. However, there are pretty simple things that you can do. For example, separating production from office with VLANs (virtual LANs, a common managed layer 2 feature) works well. Traffic is not passed between them, unless you want it to. This sort of scheme makes it pretty hard for traffic/packets on one side to affect the other. You get the benefit of being able to dynamically place machines on one side or both. VPN access is much better than a dial up. It's considerably: faster, more secure, and more flexible. Ultimately, it depends on the quality of the IT guy. If he's squared away he should be able to provide you with a transport network that is more robust and secure, and provide you with remote access, backups, and other conveniences. In that case I'd gladly follow his IP scheme. Your migration considerations might come up if you have a lot of legacy hardware that causes problems. Otherwise, what difference does it make to you? You should probably be using non-routable IP addresses following some pre-defined scheme anyway. If you jump on the IT guy's system and he does stupid things, you'll find yourself down more. Simple as that.

No problem - I stopped reading the 2nd post at ps2pdf conversion. It seems nic00 and I are recommending the same thing - well, similar tools from the same people running the same engine. Their stuff works well, though.

Wow - that's one monster rant. Entertaining as it may be, remind me to never get on your bad side.

I saw that on slashdot recently - cool stuff. They described utilizing the Piezoelectric effect on a small scale as the driving technology.

I've used Ghost Script (GSView, I think), in the past to view/print Postscript files on Windows machines. http://pages.cs.wisc.edu/~ghost/

Wow - I didn't notice any potential problems going through it, besides the fact that it won't work after Jan 19, 2038 . There are a lot of Javascript based sites and PHP scripts outs there that will quickly do the conversion. I couldn't find anything helpful (using fundamental math). I'm guessing that the Perl geeks could probably do it a little more concisely, but who cares. It looks like you did a heck of a job with that. It would probably be useful to people if you could post your Logix code snippet under the downloads section.

What kind of PLC are you using?

How do you know the user that was logged in? I can appreciate the desire to do it in the PLC. It's a more ideal location if no consideration were needed for implementation. If you're looking for: flexibility, simplicity, and more functionality in general you'll need to use a computer. I'd recommend considering FactorySQL for that purpose. Alarming is pretty trivial to set up in software and you get email (text message) notification capability in addition to SQL data logging. (I'm still pushing for a free version of FactorySQL that would do this). Alternatively, there's a whole slew of little OPC based utilities for data logging.

Nice resource Mickey. FYI, XP Home is really the same as Pro, minus the ability to log onto a Windows Domain, a web server (IIS), and a few other minor things. Plus Home "features" an obnoxious set of default settings. I personally have never seen a program work on Pro and not Home. That said, Rockwell's stance has always been that they don't officially support XP Home. I don't blame them - you don't get any guarantees from MS and think about the application for the kind of software we're discussing. Supporting irrelevant operating systems means more QA that could needlessly drive prices even higher.

Busted out the K-maps! Nice! Never seen 'em outside of Computer Science, specifically architecture or logic classes (or without De Morgan's) . They are useful, though. I'm impressed with your dedication Chako - good stuff!

I agree with Buster. I've successfully used RSLinx with a few thousand tags. It's been my experience, and I've heard from various sources, that KepServer does better with that many tags. Too bad your customer says all Rockwell - you could use all AB/Rockwell and pay their overpriced consultants too much and they're not going to guarantee that it'll work with that many tags. Not unless you unnecessarily purchase a whole lot more hardware and software. I imagine you have more sense than that since you're programming your own application.

I was thinking of Pelican when you sent that link. I've used a lot of their cases in the military. Not cheap, but the things are stur-dy.

I have a DGL-4300 "gaming" router that works pretty well. It's "Virtual Server" feature is a port forwarding option that's like your alternative, but also allows you to specify the destination port. You might also check out "hacked" firmware for common routers like the Linksys WRT-54G. 10.52.100.71:2901 <--> 192.168.201.1:80 10.52.100.71:2902 <--> 192.168.201.2:80 10.52.100.71:2903 <--> 192.168.201.3:80 Home/cheap routers call your first function a "DMZ host". I don't know of any that can support this for a range of addresses. Cisco gear can. Wouldn't you be better off asking your IT department for that capability (instead of asking for the addresses and trying to figure it out)? 1. Apparently RSLinx requires both TCP and UPD Port 2222 and Port 44818. 2. It depends what you mean by "connect them to the company LAN". A better design would be to connect to a "gateway" computer that can communicate with the PLCs. This might involve using RSLinx Gateway or an OPC Tunneling program. Better yet, it would be a server that could distribute your HMI directly.

I knew it! Ken - good luck and happy birthday. I hope you get better breaks than I did when I played last week. You don't want to hear about my luck (which wasn't augmented with nearly enough poker skill)

How do you know Ken's birthday? I'm trying to justify this one as being thoughtful and not creepy in the least...

That was a joke. I'd love to help out, though.

I think you're right that it's code 128. I took a screenshot of "L0075765 AD01" in Code 128 in FactoryPMI. It looks similar. Maybe you can tell for sure by comparing it closely to your original (or printing it and scanning it at your customers site). I looked at various other formats for that string - they looked nothing alike. Also, many barcode formats don't support letters. LMK if you need a bigger image.

Anything I can help with? I'm a master delegator

Count me in for Underdog. Thanks again for doing this, Tim.

LMAO - great response!

Just curious if anyone here uses or participates in open source industrial projects. It's a shame to hear about so many people writing the same little apps from scratch. This is kind of a version of this thread from plctalk. I got flamed for suggesting that communication drivers ought to be free. How dare I even suggest that hardware manufacturers bundle drivers with their products! Or that users contribute to something without being paid!