Nathan

TAP, I like that....TAP Co. or something. Hard to find a good web site name, though. Tapcompany and other similar ones are taken...but you'll do fine if you get creative!

I wasn't able to see the video on the other post, so I hope I'm not repeating the same thing, but that reminded me of this....I want the video if you can top it! edit DOWWW Same video..... :(....lol there are lots of videos out there of that same house and the piece with the Trans-Siberian orchestra. Some start earlier and have a bit more though. You can waste a lot of time looking through Google Video searches.

I'll second that one bigtime. Nothing worse than allowing a PC crash to wreck your process! Those 18.1 quotes are timeless classics!

Automation work definately heavily relies on word of mouth - but that's pretty tough without a name. I'll see what I can think of - What do you guys specialize in/do different. Most guys come up with some permutation of their name and "Industries" or "Control(s)" or "Automation" or "Professional" or "Concept" "Technology" or "System" or "Engineering" or use something that they specialize in.

Ken, I found the knowledgebase issue under "R146356307" in Google, but couldn't figure out how to access it on the new Knowledge Base. Am I missing something really simple in creating the username/password? edit - I did register last time and remember not being able to find the file. Using that same email login/password, I can now see the file. Edit again - I think the RS knowledge base has been smoothed out since the OP.

Ken, Please excuse my rude comment earlier. What does it take (minimum plan) to get access to the forum?

This thread is getting really good! I'm enjoying it (and learning too).

ODBC connections are really simple. They just define a database connection with the parameters you'd expect: database type, database name, address, port, username, password, etc. They're also easy to set up. You go to "Data Sources (ODBC)" in the Control Panel->Administrative tools. "User DSNs" refer to connections that are stored under that windows login name. "System DSNs" refer to connections that any user can access. The role between database and HMI is changing. Fundamentally, every HMI system needs some kind of "database". This is where it stores variables, paths to the PLC, update rates, caches PLC values locally (so it doesn't have to slam the device all the time), and most importantly, logs historical data. In the early days of HMIs it was standard practice for authors to write their own database. The sole advantage is that it can be kept hidden from the user - for simplicity. Early packages chose to use a myraid of bad ideas, typically consisting of some sort of text or binary files or their own concoction. These tended to be: difficult to back up or maintain, prone to file damage, would slow way down over time, did not do well with queries or later analysis, were not efficient in terms of file size (compression, file structure, etc). It quickly became obvious that developed SQL databases had already tackled these problems. Thay have the additional benefit of being supported by IT departments. Now, every major vendor supports SQL databases to some extent. Most have chosen to use Microsoft SQL server or a variation of it (Wonderware sells InSQL server, which is their own custom version of SQL server). They typically employ this for the "historian" (datalogging) portion of it and for: recipes, transactions, and the likes. Most of these companies still use their own local scheme for their database and communication between nodes, but use the SQL database for the larger sections of data. ie Wonderware uses Archestra, Rockwell FactoryTalk, etc. They've expanded this notion to include communication between their computers (client and server) and also PLC communication. At Inductive Automation we've chosen to use an SQL database centric model. All of our communication between HMI and PLC go through an SQL database. The advantage is simplification in setup and maintenance, and that any product that can talk to an SQL database fits right in. Many other vendors only want their own software to be compatible (they will go further and obfuscate their SQL tables, this is not necessary for performace). Our theoretical disadvantage is that there is more traffic (overhead) since everything goes through the SQL database. We've found this to be negligible since SQL databases are very fast and tend to be able to handle orders of magnitudes of data more traffic than PLCs. Hope this helps - the real answer is that the role between database and HMI is changing. To what extent depends on who you ask.

Dave, Don't let the licensing cost of HMI packages influence your decision to custom program your controls application. Jesper is dead on in emphasizing the "maintain" section. I've dealt with many custom programming installations that aren't that old, and work rather well, but are impossible to modify and maintain. After a couple of years when the technology changes it becomes considerably more difficult than dealing with an old HMI package (still a pain). I've seen such applications written in Delphi, C, VB, or whatever else. It's not the language that becomes obsolete as much as the "technology set", for lack of a better word. Applications I've run across have been DOS or UNIX based, which is difficult to support in terms of getting new hardware to work with the legacy code. Often times the technology of the communication layer to the device is the painful factor. Here's an example of difficulties on the "maintenance" front. In one case I dealt with, the computer was dying so IT ghosted (imaged) the hard drive, which caused the drive to fail. Even with the disks and documentation that the original programmer left, neither IT nor any local integrators could get the application back up. That particular machine was one of 3 that worked together, responsible for a distributed presentation layer - way ahead of its time. Your mention of SQL is good. All major vendors are moving in that direction. You should see continual support and collaboration with IT departments into the future. Besides, SQL databases are powerful, fast, and not very difficult to use. I would recommend that you evaluate HMI packages. They should allow you to create a controls application faster than you could with a programming language alone. Nobody will argue that you don't have as much flexibility with .NET, in theory you have much more, but if your time is worthwhile and the end user is interested in using/growing the project into future, consider "pre-canned" packages.

Learn something new every day. Thanks, Alaric! I'm curious to see the OP post the answer that the newsletter was looking for.

Ken's definately not a lurker by that definition. He's a very active poster. Not sure what the OP had in mind - I don't think he was referring to Ken at all.

I still fail to see the personnal attack. This is what I said, (addressed to Ken) Good point

Ken, I think you're misinterpreting a lot of what's being said here. There have been a few requests for free tech support, which may be unreasonable. Certainly high quality tech support is valuable and worth selling. I've spoken with a number of integrators who refuse to Rockwell products due to the pricing and whole picture. It's been noted that some users feel that they should get some amount of support with a multi-thousand $ package. Others are irritated at the level of support that they get for the money (the $6000 post). What bothers me is when companies charge for maintenance fees for software upgrades in order to get bug fixes. I think that if someone buys a software package and the developer updates some security flaws or other bugs, that the customer deserves the update. When I used to do integration work we had customers who bought legal copies of Rockwell software who chose not to continue with the subscription fee. We as integrators, came in with our newer software versions to modify their application, which necessarily updated them and rendered their legally purchased development software useless. What should they do, call Rockwell. You can't talk to support if you haven't purchased this years service contract. If they had purchased the contract, they would have to back pay for software updates for the years that they missed (or a penalty versus the usual update rate). I'm strongly opposed to malicious schemes that inhibit the functionality of "older" software, especially of one's own customer base. Does anybody else have simliar experiences? Am I totally coming from left field? I fail to see how Ken's post about support fees being the source of his income imply that Jim's general statements about the way Rockwell does business were a personal attack against Ken. Where has anyone attacked Ken or done anything but thank him for his posts. Nobody is attacking Ken.

Who's this addressed to and what's it about?.... [edit] Oh, Jimmy's post calling

I'm sure I'll hate Microsoft for awhile, then forget how crappy their old products were and start using IE7. Pretty soon I'll be totally happy with it and forget about the older versions. That's how it's gone with all of their other packages... Kind of reminds me of my NT 4 MCSE text - the picture illustrated that even UNIX machines could communicate with "Microsoft TCP/IP". It wasn't a year earlier when MS OSs shipped with NetBUI and they didn't promote TCP/IP. A similar illustration depicted NT servers talking to Novell machines over "Microsoft IPX/SPX"...humm.

Lol, awesome! Our forum is here. We have our own products, but I have no problem with users posting Rockwell questions - I have lots of integrators who are experienced RSBugware fighters. Our integration company used to be a "Rockwell Certified Solution Provider" - what a waste! Rockwell was nice enough to send their overpriced consultants to our customers behind our backs, though...it's gotta be tough being that good.

Smoke, ya beat me to it! Got that zero cross product goin' on....motor needs a push...shoulda used 3 phase... or maybe it was RSpowered... (Panic's on to something big ) That's a great e-newsletter idea, btw...I think I'm gonna have to "borrow" the concept....

I'm gonna try not to be "that guy", but here goes... I think open source would be great for industrial controls - but the (North American anyway) market firmly rejects it. It's hard enough to convince them to use programs like Linux or MySQL. "What real companies use those....???". I'd love to see Rockwell, Wonderware, whoever go against those titans in a stability contest! I am personally interested in open source controls projects. The ones that I have seen, mostly on Sourceforge, are pretty immature - certainly not ready for production environments. Drawbacks are that the industry is relatively small - without the economies of scale you'd have trouble getting timely support and updates without paying for it. That said, we at Inductive Automation provide unlimited, free, quality tech support to integrators and will answer any questions that our end users - or anyone, for that matter - has on our forum. But we aren't your typical industrial software company. We support the use of good free software instead of trying to write our own clunky versions, support open standards and information flow, and were started by integrators, not to mention that we have a reasonable pricing model. Here's a novel thought for industrial software giants - it does't cost you anything more for the end user to have more: tags, screens, concurrent clients, developers, etc!

Yeah, what's an OSDK? Open Source Developer Kit? ... Obsured Speed Digital Keyboardless-input...brain to mrplc forum in nanoseconds...

I'm all about going with NEMA 4X rated industrial touch computers or using standard PCs with Industrial touch LCDs. I personally like Hope Industrial displays. It's so much cheaper, easier, and more powerful. Haven't dealt with the Mitsubishis though. How are they? I have lots of stories about AB panelviews, especially the newer ones

I think I was on! Is there a way to check the listing? I know BobLfoot was on. He beats me to all the posts :)

You might also be interested in FactorySQL and FactoryPMI. They are cost effective applications to develop SQL database and web launched SCADA applications. They are easy to use and programmatically very powerful. If you choose to write your own SCADA application, use the OPC foundation source code libraries to communicate with your OPC server. I believe that you need an OPC member login to download the code. LMK if you're having trouble getting it.

Lol, I've felt similar pain before.

Cool deal. I'll check out the site as it grows. You might want to force more content into the forum to get it started and get more general info in the site. Also, the purple search page looks really bad, you might want to work on that one. Looks good all in all.

The subnet mask doesn't need to be 255.255.0.0, but that would probably be the easiest. If you wanted to follow convention you'd use the 172.16-31.*.* range for the non-routable Class B addresses (65,536 addresses). 192.168.*.* is the Class C range of non-routable addresses (255 addresses) and (by convention) you've chosen 3 subnets then wanted to merge them. If binary math isn't your forte do a search under "subnet mask calculator" in Google. For example here