Nathan

For general purpose programming/application use, I think Java is way better - but the learning curve is much steeper for a "non-programmer". This should especially be true with all the cool things that Java 6 update 10 brings to the table. Python is a great way to learn to program from scratch. For more serious python development, check out pydev. It runs in Eclipse. I haven't had the need to use it.

Lol, I know the feeling. It made me hate lists. Good stuff with the DCS - that's how it should be.

The VB statement has been true in the last decade for HMIs, but is losing momentum. VBA has been included because HMI packages were all written for Windows and MS made this development relatively easy. The "HMI flavor" VB has been easy enough to learn, but leaves a lot to be desired in terms of capabilities. Wonderware has their home grown thing, Citect uses CiCode, Inductive Automation uses Python, Intellution and Rockwell still support VBA. As far as the future goes, Microsoft is pushing .NET based scripting, which is syntactically similar to, but incompatible with the flavor of VBA we're referring to. It really makes sense to go for a platform independent and PC industry standard language. MS has a history of releasing new versions/service packs that are backward incompatible with their customer base. My personal preference is Python, PHP, or Ruby (only dabbled with). IMO Perl belongs in the textbooks with LISP and Prolog. The only thing worse are the home grown languages that HMI vendors invent. Try finding a book on Cicode. You won't, but a Pascal book would get you started. +2 with Alaric on structured languages.

You'll learn a thing or two listening to Bob! Software programming experience is helpful, but not usually directly applicable - you'll know if you need to use it. If you do go down the embedded software route, C will likely be your language, not C++ and certainly not C#. C Sharp is one language in the Microsoft .NET suite that compiles code to an intermediate language (bytecode) to run on a virtual machine (like Java). There are a lot of advantages and reasons to go this route, but not really for embedded devices. The language could be relevant to create an HMI or HMI development suite, but then you should learn software engineering techniques rather than (or in addition to) programming. At that point you're way outside "PLCs".

Lol - this is one of those threads that will never die - Like the infamous PLC law thread!

Awesome! Glad to hear that you were successful.

Ken's right. Keep in mind that if you do go with fiber you'll likely need "media converters" to convert back to copper for your EtherNet module and PC. If you're not much more than 100 Meters just put a switch somewhere in the middle and run Cat 5/5e/6 wire from each node to the switch. This is the easy/cheap way to go.

Nice work. All your requests are pretty straightforward. LMK if you have any questions.

Ron beat me to it. Pretty bad deal if they won't provide your files if you ask.

I've never done this with E900 equipment, but can safely say that access should run faster - much closer to how it runs locally. Try launching a web browser locally (on the same computer or on a machine on the same LAN). Are you trying to connect two sites or allow remote access from over the Internet? Will you or someone else set up this connection? You want to ensure that the IP addresses are in the same subnet on both sides - or at least that they can communicate. This isn't difficult, but there are a lot of variables.

I agree - all else being equal, standardization is always a good idea. Out of curiosity, did you use any of the following techniques in FactorySQL for setting up all those tags: 1. Dragging down entire "files" to recursively set up groups/tags 2. Copy/Paste and search/replace for sets of tags with similar paths 3. Import/Export to .CSV and use the magic of Excel

I used to use Paypal a lot. Haven't in a while. Have never had, or heard stories of significant problems. With the exception of social engineering (users being retarded), you should be fine. I would tend to use credit cards over debit cards for protection reasons.

Many different OPC servers should work. Matrikon makes another driver. Data logging programs like FactorySQL or OPC datahub will interact with the PLC via the OPC server (RSLinx, Kepware, Matrikon, etc) and deal with SQL databases.

Uh, "online training" here in America? Doesn't that defeat the point of "online"?

You could pick up their book for a fraction of the price for a good preview. I'm interested in user feedback about online IDC training. This is the first I've heard about them.

Happy B-Day!

Oh good - so it does appear that the software supports multiple languages! Why I couldn't find that feature set on their web site, I have no idea!

I was too busy laughing at the code to notice that it pointed to your blog. Nice! Added a link on my blogroll.

I don't have a real good answer to your question, but I can provide input. Trying to support Internationalization/localization in a package that doesn't support it is begging for trouble! Particularly so with RSView, which, (correct me if I'm wrong) doesn't even support unicode. (Basically saying the same thing as Paul was with I18N support). Double stacking everything is a horrible idea for many reasons. Maintaining the project will be easily twice the work, the project is double loading everything in memory, and maintaining consistent changes will be a nightmare. You're setting yourself up for failure with that decision! If you really need muli-language support AND you're stuck with a package that doesn't support it, consider maintaining 2 separate projects. Complete one in your "main" language before duplicating it and changing the labels. This still requires exactly double the work (bad), but at least you're not creating a *cluster of layered confusion. Don't believe me? Create one moderately complex screen that way, then make a significant change. Bad ju ju. Bottom line - you may be trying to use a hammer as a wrench. Either find the right tool or do what you can to minimize the pain.

You might also consider devices that work over your local cell phone network. These tend to be robust and fairly simple You can often get a secure broadband data connection cheaper than a satellite link. I can't speak to service in Australia, though.

I like your sig!

We had 50+ CF-50s for several years and now have at least that many CF-51s (now replaced by the CF-52). They're decent and reasonably rugged. I've used them in light rain, for example. I don't think they're as rugged as Panasonic used to make them (or perhaps other lines). From an administrative perspective they're a bit of a pain since they aren't consistent on OEM hardware between lots. In other words, you could have several CF-52s ordered under the same configuration that run different hardware/drivers. Dell is the only vendor that I know of that standardizes on components within models (in the "business" line) - so you get the same issues with their "Inspiron" models, for example. All in all, we've had them break just like Dell laptops and any others. I tend to be a Dell fan in general. I also like IBM and Panasonic laptops, but they are more expensive.

Good God - RA Lawyers must have had a field day! I'm glad to see that you at MrPLC are doing your best to be accommodating. I would have thought that Rockwell would appreciate help disseminating their content.

Happy B-Day! Hopefully you don't read this until tomorrow. Not likely, though...

I'd tend to agree with Ron on this one - What an excellent opportunity for you to learn a wide variety of systems. As far as management purchasing a hodge podge of brands because they're functionally "the same" - what a terrible idea - an exercise in poor decision making and an interoperability/support nightmare! The marginal savings will be significantly overshadowed by systems that aren't maintainable. Projects may need to be recreated, software/support purchased, etc. I don't agree with the opposite end of the spectrum (dictating a single brand as your corporate standard regardless of the problem), but this approach has to be the absolute worst. It's all about creating a workable "happy medium" that's consistent and consolidated, yet flexible enough to meet your needs.